MHonArc v2.5.2 -->
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
Mike - my comments are embedded in [CL] tags.
Best regards
Carsten Leue
-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory B�blingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
|---------+----------------------------->
| | Michael Freedman |
| | <Michael.Freedman@|
| | oracle.com> |
| | |
| | 06/14/2002 03:59 |
| | AM |
| | Please respond to |
| | Michael Freedman |
| | |
|---------+----------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: wsia <wsia@lists.oasis-open.org>, WSRP <wsrp@lists.oasis-open.org>, wsrp-interfaces@lists.oasis-open.org, |
| wsrp-wsia@lists.oasis-open.org |
| cc: |
| 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
[CL] Then I misexplained this. The goal was that both a persistent and a
transient entity would be represented by a handle to the consumer. The
consumer stores this handle to refer to it later (is it this you call a
"consumer reference"?) [CL]
-- that a transient entity did this.
[CL] No, persistent and transient entities are only distinguished by the
lifetime of their state. [CL]
I.e. I want to be able to
have 2 portlets in a consumer that share the same persistence record.
[CL] Why would I want this? Isn't a portlet meant to represent configurable
state? What would be the usecase of putting two identical portlet on a
page.
My view on things is the following:
1. you might have a portlet template that might be associated with some
persistent data record on the provider
2. what you put on a page is a persistent entity that might derive form
such a template. Two entities share the template's persistent data but
consist also of two persistent data records that distinguish them
Is it the template's persistent data you want to shate?
[CL]
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).
[CL] Maybe we can leave transient entities out in the initial discussion
and focus on persistent entities, templates and sessions.
[CL]
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.
[CL] I do not understand your last statement. Could you elaborate a bit on
it or rephrase it [CL]
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.
[CL] Yes, I also think that the session concept begins to stabilize [CL]
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.
[CL] I would like to hear more feedback on this by the other members of the
comittee. Is the draft really that fuzzy? [CL]
-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