My personal take is that we should leave time in the F2F for this topic.
But in any case, I believe there's also another
variation, which is similar semantically but different syntactically.
Instead of the Consumer having to store and pass a groupID, which the
Producer needs to declare and understand, one may consider the following twist,
which is similar to the way we handle sessions:
- rename initEnvironment() to createPortletGroup() --> returns a
groupdID generated by the Producer
- Producer metadata may include a "groupable" flag, saying whether
entities under this Producer service are groupable. Alternatively,
this operation can be placed in a different port type to denote that
no grouping is allowed
- In case grouping is supported, the Consumer may call
createPortletGroup() before interacting with entities, getting back a
groupID
- The Consumer passes that groupID to every portlet that it decides
should be within this group
- By convention, it also passes the HTTP
cookies
This allows the Consumer to manage the grouping in any way it pleases in
a way that's completely transparent to the Producer. The Producer only specifies
if that's doable or not (easy).
One may also extend the meta-data to support a way for the Consumer to
achieve the level of granularity that Rich suggests without changing the actual
protocol.
--Eilon
-----Original Message----- From: Rich
Thompson [mailto:richt2@us.ibm.com] Sent: Friday, October 11, 2002
9:38 AM To: wsrp-wsia@lists.oasis-open.org Subject: Re:
[wsrp-wsia] [wsrp] initEnvironment and groupID - my final thoughts before we
vote
You state that "initEnvironment() satisfies/supports JSR 168"
... from our recent discussion of this topic, this is
true only if there is a Producer per portlet
application. In considering whether this will be a reasonable restriction, I would like to see some estimates of the number of
portlet applications in a typical portal deployment. I
wonder whether this would be an acceptable restriction
to spec implementations/deployments. It has significant impacts on areas such as registration. I would also note
that there have been 2 proposed means for the Producer
to achieve the necessary function without
initEnvironment().
My personal preference is that if we introduce the concept
of Producer-mediated sharing into the protocol at all,
it should include Consumer specified scoping on that
sharing. The possibility I have heard proposed for
this is:
- The entity metadata includes a "preferredGroupID". For
JSR168, this maps directly to the portlet application
name. - The protocol includes groupID in the
current manner with the semantics tightened to require
the Producer to scope any data sharing by the supplied groupID. The Producer would still be free to further scope the data
sharing according to its policies.
This combination allows Producers to scope data sharing more
tightly than the Consumer specifies, but does not
allow crossing the Consumer specified boundary
(supports the often mentioned a1/b1 & a2/b2 on the same page use
case).
If we do not introduce Consumer scoping of the data sharing,
then I again question what the Producer-mediated data
sharing concept is doing in the protocol.
Michael
Freedman
<Michael.Freedman@
To:
wsrp-wsia@lists.oasis-open.org
oracle.com>
cc:
Subject: Re: [wsrp-wsia] [wsrp] initEnvironment and groupID - my
10/10/2002 02:12
final thoughts before we
vote
PM
Well, I think Andre may be technically correct -- in that the
servlet architecture allows one to place a filter in
front of the a [set of] applications and this filter
could implement/expose its own notion of HttpSession
for the application on top of/within the HttpSession established between the consumer and the
producer. It would be an extraordinary implementation. Without writing such special code to mimic the
true servlet session, Carsten
you are right that one ends up with a single JSR application per producer. However, even
in Andre's situation there is no need for a group ID. The producer has the
information available to it do the proper filtering/partitioning without any consumer management.
In the end Carsten, I think your e-mail lays out the
discussion very well. We know
that initEnvironment() satisfies/supports JSR 168. So the
question before us is what
level of support do we want for non-JSR environments?
There are only three choices: 1) No [additional] sharing is defined by the
protocol. Any [additional] sharing information
has to be carried entirely via the extension mechanism. 2) The protocol defines very specific consumer semantics for at
least one form of sharing. Vendors can choose to
further extend this semantic via the extension mechanism. 3) The protocol
allows a producer to express very specific producer semantics for at least one form of
sharing. Vendors can choose to further extend this semtanic via the extension
mechanism.
Currently, the specification tries to do 2. It defines a
"groupID" to carry a consumers
notion of how portlets are grouped. It further states. "Section
7.1.1 (page 31, line 20): "Since Consumers will not know what
entities could benefit from
any Producer mediated data sharing, they SHOULD place all entities from a Producer within a single group
until a reason is identified for specifying a separate
groupID." This definition has two problems. It neither defines a specific semantic (it uses
the term SHOULD) nor is the semantic useful.
I suggest that our default choice should be (1). Sharing
is not defined and therefore
must be added as a vendor extension. For those of you that would
like to see sharing in v1, whether of the form (2) or (3), I
think your burden is to
provide us with a clearly defined semantic and to get consensus from
all of us that all consumers
will/should support this semantic [in v1]. Though I have heard arguments for keeping sharing I
haven't yet seen a proposal that defines its semantics
clearly. Does anyone want to make a proposal?
-Mike-
----------------------------------------------------------------
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>
|