[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