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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsia message

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


Subject: Re: [wsia][wsrp][wsrp-wsia joint interfaces]: An alternative


I understood from the draft that a persistent entity referred to "remote portlet logic" + persistent data.   But does persistent entity also refer to
a particular consumer reference of such a thing?  My read of the spec was it did not -- that a transient entity did this.  I.e. I want to be able to
have 2 portlets in a consumer that share the same persistence record.  I have noticed that transient enitites (and objects in general) seem to be
leading to a lot of confusion in our expert group.  My proposal is an attempt to look at our problem from a different perspective to see if we end up
with something less confusing to ourselves and then hopefully to others.  So as I e-mailed in another message, I suggest we look at things less like
objects and more as scopes (references).

Furthermore I wasn't trying to say that one model has fewer references then another.  You are correct that the number of references are the same.
The difference is the number of reference that are maintained/managed.  When the consumer (is a portal) supplies the references, these references
will likely be able to be (er)constructed vs. maintained in some sort of key map table.  Likewise, the producer will only maintain those keys that
are pertinent to it.  I.e. if there is no transient state it merely ignores the reference vs. had to figure out it should manufacture a constant
dummy one for the consumer.

Lastly, I think we are on the same page regarding sessions.  I agree that the session scope is a shared scope between all entities within a producer
that a consumer chooses to group together.  This can be all the entities of the producer, a subset of entities, and even at the extreme one session
per entity.

In the end, my proposal is just a concrete attempt at asking ourselves should we look at the problem a little differently since the current model
continues to generate confusion and concern?  At the least, I hope that looking at this problem from another perspective allows us to clarify/improve
the current draft.  However, I am also open to going down this/a different path if we feel like the end result is simpler or less confusing.
     -Mike-




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


Powered by eList eXpress LLC