[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
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC