[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp-wsia] Issues #6 - Is groupID required?
I think string for ID and int for number of portlets makes more sense, though I am not sure why we need the number of portlets. What Mike was suggesting ought to be a boolean, it seems to me. The only information it provides is whether or not there is a group of portlets in the entity. However, on the producer side could there be good reasons for more than one group of portlets per consumer and/or per user-client? Ciao, Rex At 8:09 AM -0400 10/21/02, Rich Thompson wrote: >I see two basic changes in what Mike is proposing: > >1) Change groupID from a String to an int. While this may seem like a >simplification, the most natural way to represent a group in Web terms is a >URI (subset of the string lexical space). We should have very strong >reasons if we step away from this, in fact we may want to explicitly make >this of type 'xsd:anyURI'. > >2) Have the Producer specify the number of times initEnvironment() must be >called per user. This can be quite inefficient for Producers hosting many >groups. Having the Consumer determine the number of invocations based on >the unique groupIDs the End-User is interacting with sure seems like the >most efficient process. > >Now that the semantics for groupID are tightening up, I think the operation >name needs to be changed to initGroup(). It is all about the Consumer >enabling the Producer specified groupings. I also think it should carry the >groupID it is targeting (in case the Producer cares) and return an <any/> >in order to remove the protocol dependence. I guess we would then have to >define where the Consumer MUST return whatever the <any/> contained .... > > > > > Gil Tayar > <Gil.Tayar@webcol To: >wsrp-wsia@lists.oasis-open.org > lage.com> cc: > Subject: RE: >[wsrp-wsia] Issues #6 - Is groupID required? > 10/20/2002 12:57 > AM > > > > > >Mike, > >I'm not sure how this makes things simpler than Carsten's proposal (which I >like, by the way). All you are suggesting (from what I understand) is to >replace Carsten's unnamed "application ID" to an "environment ID" that is >numeric, and adding a field in the metadata containing the number of >"environments/applications" there are in the Producer. > >If that is the case, and I haven't missed anything, I would prefer >"application ID" as it is more flexible, and more XML-ish than numeric ID. >The Consumer will anyway have to have a map that groups all entities, and >keying that map to an integer vs. a string doesn't seem a big difference. > >Gil > -----Original Message----- > From: Michael Freedman [mailto:Michael.Freedman@oracle.com] > Sent: Sat, October 19, 2002 20:11 > To: wsrp-wsia@lists.oasis-open.org > Subject: Re: [wsrp-wsia] Issues #6 - Is groupID required? > > Carsten, > This looks good, but I think we can [and should] make it a little > simpler. Basically, as groupID is no longer carried over the wire we > need not concern ourselves with arbitrary group names. I suggest we > do the following: > 1) We change the doInitEnvironment field in ServiceDescription to > something like numInitEnvironments. numInitEnvironment would be an > int. A value of 0 would mean initEnvironment should not be called. > A number > 0 indicates how many initEnvironments the producer > requires. > 2) We change the groupID field in EntityDescription to something > like environmentID. environmentID would be an int. Its value would > be between 1 and numInitEnvironment inclusive. If numInitEnvironment > is 0 or 1 the environmentID field is ignored by the consumer. [When > numInitEnvironment is 0 this field can be ignored because there are > no environments. When numInitEnvironment is 1 this field can be > ignored because all entities are in the 1 enviornment.] If > 1, > environmentID indicates the environmental context that should be used > when interacting with this entity. Values outside the range [or > missing] signify invalid entity descriptions. Consumers must not > activate/use such entities. > > > This simplification makes consumer management/lookup simpler and more > efficient and seemingly loses nothing on the producer side. > -Mike- > > > Carsten Leue wrote: > Hi all. > > > As discussed on Thurday's call here is a writeup of the > proposal we > discussed. > > > procedure: > 1. the producer tells via metadata what entities belong to an > application. > The producer assigns an ID (or name) for each such group. This > name should > ideally be globally unique. > 2. the consumer MUST respect the metadata grouping information. > It MUST > call initEnvironment for each user session prior to making a > call to any > entity that belongs to a group. > 3. it would not be required to transfer the grouping-metadata > at all across > the wire, so we could remove groupID (see the disadvantages > section) > 4. the consumer must respect cookies and headers in the HTTP > case > > > advantages: > - no explicit groupID mechanism that pollutes the protocol > - compliance with JSR168 > > > disadvantes: > - we lose our per-instance grouping concept > - functionality depends on metadata-awareness > > > comments: > to 1: in the JSR168 case the producer will choose the > application ID as the > groupID > to 2: calling initEnvironment on a per-group basis provides a > simple (yet > protocol dependent) mechanism for the producer to support > multiple JSR 168 > applications. As each application requires an HTTP session and > the JSR168 > producer respects (1), the call to initEnvironment establishes > such an HTTP > session. Together with (4), ensuring that the session will be > kept, the > producer can reuse this session between the consumer and the > producer > directly as the HTTP session required by the JSR. No > re-implementation of > session management on the producer would be required. > to 3: after the session has been established the groupID does > not to travel > over the wire as the HTTP together with the entityHandle > implies the > appropriate grouping on the producer. This implies that the > consumer side > grouping equals exactly the producer side grouping. (1),(2) and > (4) ensure > that. > > > Comments? > > > Best regards > Carsten Leue > > > ------- > Dr. Carsten Leue > Dept.8288, IBM Laboratory Böblingen , Germany > Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401 > > > ---------------------------------------------------------------- > > 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> -- Rex Brooks Starbourne Communications Design 1361-A Addison, Berkeley, CA 94702 *510-849-2309 http://www.starbourne.com * rexb@starbourne.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC