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

[Michael Freedman <Michael.Freedman@oracle.com>]

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-