[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
Is the consumer persisting the navigational data? I don't think it is, and this is the kind of storing Gil was referring to (I think). Yossi. -----Original Message----- From: Carsten Leue [mailto:CLEUE@de.ibm.com] Sent: Tuesday, September 24, 2002 1:40 PM To: Gil Tayar Cc: wsrp-wsia@lists.oasis-open.org Subject: RE: [wsrp-wsia] [I#92] Maximum size of a handle Wouln't it be wiser for the stateless producer to store real data in the navigational state rather than in the sessionID. I view this value as well as something static (of course it can be misused). But we should not encourage portlet writers to use the sessionID as a datastore. I would be fine with small sessionID sizes. Best regards Carsten Leue ------- Dr. Carsten Leue Dept.8288, IBM Laboratory Böblingen , Germany Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401 |---------+----------------------------> | | Gil Tayar | | | <Gil.Tayar@webcol| | | lage.com> | | | | | | 09/24/2002 05:50 | | | AM | |---------+----------------------------> >-------------------------------------------------------------------------------------------------------------------------------| | | | To: wsrp-wsia@lists.oasis-open.org | | cc: | | Subject: RE: [wsrp-wsia] [I#92] Maximum size of a handle | | | | | >-------------------------------------------------------------------------------------------------------------------------------| The problem with moving to small (<128 byte) handles is that it precludes _stateless_ producers from storing things in these various handles. Remember that refHandle today = entityHandle + sessionID. The sessionID can be used to store information in a stateless Producer, and thus should be allowed to be bigger than 128 bytes. -----Original Message----- From: Rich Thompson [mailto:richt2@us.ibm.com] Sent: Mon, September 23, 2002 20:08 To: wsrp-wsia@lists.oasis-open.org 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> ---------------------------------------------------------------- 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