OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [wsrp-wsia] [I#92] Maximum size of a handle



Before we go too far down this path, I would like to know the use case for
handles being in the kilobyte+ size range. They are defined to be opaque
references and our basic use case has Consumers managing huge numbers of
them. Unless we have some other significant use case, I would consider a
design that guarantees these Consumers can not take advantage of common
database efficiencies (ie. will perform poorly) to be a very bad choice. In
fact, because of the significance of this use case, I would think any
design that did not explicitly consider how Consumers may efficiently
manage handles to be less than fully baked.



                                                                                                                 
                      Sasha Aickin                                                                               
                      <AlexanderA@plumt        To:       "Tamari, Yossi" <yossi.tamari@sap.com>, Gil Tayar       
                      ree.com>                  <Gil.Tayar@webcollage.com>, wsrp-wsia@lists.oasis-open.org       
                                               cc:                                                               
                      09/23/2002 12:53         Subject:  RE: [wsrp-wsia] [I#92] Maximum size of a handle         
                      PM                                                                                         
                                                                                                                 
                                                                                                                 



I'd rather have no hard number whatsoever in the spec, for reasons that
both Yossi and Eilon have put forward.  That being said, I'm basically ok
with this proposal.

However, if we do choose to have a hard number, I think we should establish
what the units are (characters or bytes?) and what the exact number is
(most people interpret K to mean 1000, computer science people interpret it
as 1024).  I think it makes more sense to use characters as the unit and to
use a human-understandable number (i.e. not a power of 2).  This would
change the proposal to: "... MUST support a handle of at least 4000
characters, but SHOULD support a handle of any size.  (Note that this
minimum supported handle size is measured in characters, not in bytes.
Since many codepages encode a character using more than one byte, a handle
of 4000 characters may be transferred across the wire with more than 4000
bytes.)  Portlets SHOULD...".

Sasha.

-----Original Message-----
From: Tamari, Yossi [mailto:yossi.tamari@sap.com]
Sent: Monday, September 23, 2002 12:39 AM
To: 'Gil Tayar'; wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#92] Maximum size of a handle


I would suggest "...Portlets SHOULD minimize the size of the handle, and
use techniques..."
As a consumer I would much rather get a handle of less then 4K...

             Yossi.

-----Original Message-----
From: Gil Tayar [mailto:Gil.Tayar@webcollage.com]
Sent: Monday, September 23, 2002 7:33 AM
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#92] Maximum size of a handle


OK, so here goes -

Proposal -
put the following statement (somewhere...) -

"a portal MUST support a handle of at least 4K, but SHOULD support a handle
of any size. Portlets SHOULD  limit the size of the handle to this size,
and
use techniques like returning a handle to producer-side state to do this,
in
consideration of the fact that portals must store a considerable number of
these handles."

-----Original Message-----
From: Tamari, Yossi [mailto:yossi.tamari@sap.com]
Sent: Sun, September 22, 2002 12:00
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#92] Maximum size of a handle


I agree with Eilon (and Gil, and Sasha). I don't think we should put a
limit
on handle (and other opaque strings) size, but we can make some general
recommendation in the spec that producers should not abuse this.
There are many places in the spec where a producer can push a long string
to
the consumer (state for example), and we are not limiting those, so I would
say the issue is there anyway, and there is no point in singling out the
handles.
We defined as a goal to make life simple for the producer, even at a cost
to
the consumer. Forcing producers to create aliases  or in some other way
"compress" their handles is not in line with this goal.

             Yossi.

-----Original Message-----
From: Eilon Reshef [mailto:eilon.reshef@webcollage.com]
Sent: Saturday, September 21, 2002 5:57 AM
To: 'Thomas Schaeck'; 'Sasha Aickin'
Cc: 'Gil Tayar'; wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#92] Maximum size of a handle


There are many other things portlets can do that cause inefficiencies at
the portal end: they can return inefficient markup, respond slowly in
general, or present user-ineffective user interface (including offensive
language ;-). Portlet developers should definitely be encouraged to
avoid any inefficiency: namely, to use short handles, to return
optimized HTML, and to respond quickly to requests. However, it is
unclear whether those considerations should be quantitatively specified
in the standard.

One approach we can take, if people think that's helpful, is to say that
in order to be a WSRP-compliant portal, a portal MUST support a handle
of at least N (and that N should definitely be large enough to remove
any practical constraint, say 4K), but SHOULD support a handle of any
size. What this would mean in practice, however, is that most portals
would use strings to store handles in memory and blobs to store handles
in the database so I am not sure that buys us much.

--Eilon

-----Original Message-----
From: Thomas Schaeck [mailto:SCHAECK@de.ibm.com]
Sent: Friday, September 20, 2002 9:47 AM
To: Sasha Aickin
Cc: Gil Tayar; wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#92] Maximum size of a handle


One thing to consider is that there are portals with large user
populations
- potentially millions. An *unlimited* handle length formally means that
portals must be able to handle handles that of unlimited size to be WSRP
compliant which is impractical for many scenarios.

Also, this would encourage some WSRP producers to use the handles for
storing large amounts of data.

Best regards,

Thomas



Sasha Aickin <AlexanderA@plumtree.com> on 09/20/2002 12:18:59 AM

To:    Gil Tayar <Gil.Tayar@webcollage.com>,
wsrp-wsia@lists.oasis-open.org
cc:
Subject:    RE: [wsrp-wsia] [I#92] Maximum size of a handle



URLs can easily be a few KB, especially if they involve URL-encoded
non-ASCII characters.  I'm personally not a fan of any limit for handle
length in the spec; I think that any length we give is fairly arbitrary
and will come back to bite us.

S.

-----Original Message-----
From: Gil Tayar [mailto:Gil.Tayar@webcollage.com]
Sent: Thursday, September 19, 2002 4:01 AM
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#92] Maximum size of a handle


As long as it's SHOULD and not MUST, it is OK, but anyway the 128 number
is too small. Our current implementation uses a URL as the
"entityHandle" (a la Web philosophy), and URL-s can approach 128. A
1K-4K minimum (SHOULD, not
MUST) would be logical to me.

Gil

-----Original Message-----
From: Gil Tayar [mailto:Gil.Tayar@webcollage.com]
Sent: Thu, September 19, 2002 08:40
To: wsrp-wsia@lists.oasis-open.org
Subject: [wsrp-wsia] [I#92] Maximum size of a handle


Topic:  interface
Class:  Minor Technical
Title:  Maximum size of a handle
Document Section: throughout
Description:
Current draft spec just says that a handle is a string. For reasons of
efficient processing, it would be useful to limit the length of the
handle to something reasonable. Considering that an entityHandle SHOULD
encode the consumerHandle when Consumer side persitence is used and that
a refHandle encodes an entityHandle and a sessionHandle, the length
should not be too small. Suggestion = 128 characters.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%
Discussion:

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>




----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>







[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC