[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp-wsia] Issues #6 - Is groupID required?
Eilon - I think that I like your second approach - with one modification it would allow us to at least be compatible to JSR 168: procedure: - the producer tells via metadata what portlets belong to an application - the consumer MUST respect the metadata grouping information. It MUST serialize the first call in a session. - it would not be required to transfer the grouping-metadata at all across the wire - the consumer must respect cookies and headers in the HTTP case advantages: - no initEnvironment that it only required to establish protocol specific initializations - no explicit groupID mechanism that pollutes the protocol - compliance with JSR168 disadvantes: - we lose our per-instance grouping concept - functionality depends on metadata-awareness Best regards Carsten Leue ------- Dr. Carsten Leue Dept.8288, IBM Laboratory Böblingen , Germany Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401 Eilon Reshef <eilon.reshef@web collage.com> To wsrp-wsia@lists.oasis-open.org 10/16/2002 05:08 cc PM Subject RE: [wsrp-wsia] Issues #6 - Is groupID required? Rich, In general, I also share what I think is your approach which is either - we decide that grouping is important, and provide some flexibility in it (i.e., add a GroupID + meta-info) - we decide that grouping is unimportant, and try to find ways to eliminate initEnvironment altogether (e.g., meta-info that tells the Consumer to serialize the first call to a specific Producer) (I.e., I wouldn't put a complete new explicit concept, initEnvironment, if we use it just for load balancing and there are other ways to solve the problem) Having said that, I believe that the scenarios you illustrated below can be implemented without a GroupID - the Producer can store (as part of the Consumer-configured-entity) the group id in a way that's opaque to the Consumer, and allow the user to enter it in Edit mode. So, the end user can still control grouping, although in a way that's transparent to the Consumer system. Thus, in your scenario, the Consumer would have 6 portlets: P1 P2 P5 P1' P2' P3 P1, P2 and P5 would point to G1 (stored opaquely at the Producer) P1', P2' and P3 would point to G2 (stored opaquely at the Producer) The Producer uses this information to segregate the sessions, turning grouping into a recommended best practice rather than a feature of the API. --Eilon -----Original Message----- From: Rich Thompson [mailto:richt2@us.ibm.com] Sent: Wednesday, October 16, 2002 10:50 AM To: wsrp-wsia@lists.oasis-open.org Subject: Re: [wsrp-wsia] Issues #6 - Is groupID required? Lets consider a concrete example: Presume a Producer (JSR168 semantics) exposes the following entities: PreferredGroupID EntityName Group1 P1 Group1 P2 Group1 P3 Group2 P4 Group2 P5 The Consumer assigns the following grouping: groupID Entity G1 P1 G1 P2 G1 P5 G2 P1 (2nd instance on page) G2 P2 (2nd instance on page) G3 P3 Key questions: 1) Is there value to having the Consumer isolate the 2 instances of P1 from each other? I think the answer is yes. 2) Should the Consumer be allowed to place P5 in G1 despite this going against the "preference" of the Producer? I can go either way on this. If it is allowed, then Producers where data sharing semantics would not allow these to share data (i.e. JSR168) should define their own sharing scopes within the Consumer's specification to enforce their policies. Producers without such policies could pass through the Consumer's sharing specifications. I can also argue that the Producer specification should be taken as more than a hint and therefore it is invalid for the consumer to include P5 in G1. 3) Should the Consumer be allowed to isolate entities the Producer has grouped? In other words, should the Consumer be forced to place P3 in one of the other groups? I think there is always value in allowing such partial groups and would prefer the Consumer have this flexibility. I hope this helps, but since I wasn't the originator of this proposal I also hope I haven't gone way off base on what was proposed. Michael Freedman <Michael.Freedman@ To: wsrp-wsia@lists.oasis-open.org oracle.com> cc: Subject: Re: [wsrp-wsia] Issues #6 - Is groupID required? 10/15/2002 03:45 PM Rich, On proposal (1), you state it "requires that the Producer mediated sharing is scoped to all of the entities it exposes". I think it might be fairer to state: "In our protocol, Producer-mediated sharing is scoped to all of the entities it exposes. Producers needing finer grained sharing are free to implement this function transparently to the consumer within this scope". I.e. The function defined in proposal (2), is easily implemented entirely within the producer without exposing any notion of groupID. As for proposal (2), that do we think the value of tighter "grouping" is? I recall two have been discussed: (1) used to isolate two instances of a portlet from each other -- i.e. a portlet doesn't have to worry about colliding with other instances of itself in this shared space (2) a way to pass/manage sharing between a set of portlets. I don't see how either of these is satisfied by your second proposal. If I understand it correctly, the preferredGroupID is at the entity [type] level not the per entity level. I.e. all consumer configured entities derived from this proffered entity get the same preferredGroupID. If this is the case then value (1) cited above isn't achieved. As value (2) is just an extension of (1) -- i.e. the use case is meant to group a specific set of entities -- not all consumer configured entities + its prooffered entity, it also isn't achieved. Can you explain the usage case proposal (2) addresses? -Mike- Rich Thompson wrote: > We need to reach a decision on this ... basically everyone agrees that the > semantics in draft v0.7 need clarification for this to be useful. The > 2 proposals we have had put forward are: > > 1) Remove groupID from the protocol as we have no specific semantics > for it. > - It has been noted that this, combined with keeping initEnvironment > (), requires that the Producer-mediated sharing is scoped to all of > the entities it exposes. > > 2) Add entity metadata for "preferredGroupID" - Allows Producers to expose > the effect of their data sharing policies. > Add semantics to groupID that it specifies Consumer-level scoping > on the Producer-mediated data sharing. This allows the Producer to > define finer levels of data-sharing scopes, but does not allow those > to cross the > Consumer-specified scoping. This would be added as a MUST restriction > on the Producer. > > I have tried to represent these proposals objectively (sorry if I > failed to > do so). In order to reach a decision, we need explicit pro/con > statements for these proposals and I would ask their proponents to > post them ASAP. > > ---------------------------------------------------------------- > 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