OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [wsrp-wsia] [wsrp] initEnvironment and groupID - my final thoughtsbefore we vote


Title: Message
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>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC