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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

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


Subject: Re: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec0.43]Persistent Information Scope


On the question of why createEntity takes a handle:
I have interpreted this as a templeting or inheritance mechanism.  Effectively
its another way of representing copyEntity().  The new entity  is created with
the (persistent) state of the original vs. the default state from its internal
configuration/implementation.  If this is what the interface intends then we may
need to also consider an API such as:
  createEntity(consumerId, parentEntity, parentData);

parentData is the persistent data for the parentEntity as maintained by the
consumer -- for those cases where the consumer maitnains this information and
pushes to the producer.
     -Mike-

Gil Tayar wrote:

> See below.
>
> -----Original Message-----
> From: Rich Thompson [mailto:richt2@us.ibm.com]
> Sent: Thursday, May 23, 2002 14:53
> To: wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org
> Subject: RE: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec
> 0.43]Pers istent Information Scope
>
> I'm wondering if we need more than Mike's 3rd point in order to enable 'per
> consumer scope'. If the Consumer has control over when various persistent
> information is to be used, doesn't that provide more than enough control to
> have a scope at the level of the Consumer itself?
>
> > I'm not sure I get you. Michael is saying (I think) that all you _can_ say
> is
> > that the information is persistent, not to who it should be resent. So, in
> > effect, it is the Consumer who decides what the scope of the persistent
> information
> > is. Usually, it will be per portlet instance (as WSRP defines it), but the
> Consumer
> > can do whatever it wants.
>
> Also, if the operation
> createEntity() takes a handle as a parameter, aren't we explicitly saying
> that entities live in a hierarchy with the Consumer having control over how
> the branching within that hierarchy occurs? I also think it would be wise
> for Producers to also scope the entire (Consumer controlled) hierarchy by
> Consumer, but haven't thought through the implications of trying to require
> such a scoping.
>
> > Rich, I actually didn't understand why createEntity took a handle. A
> handle to what?
> > In any case, as I was saying in my following emails, I would prefer to
> defer discussions
> > of persistency to WSRP, and just give a "hook" to that persistent
> information using
> > a "binding key" (see my other emails). _At least_ we should start by
> ignoring this difficult
> > issue and concentrate on the session Lifecycle.
>
>
>
>                       Gil Tayar
>
>                       <Gil.Tayar@webcol        To:
> wsia@lists.oasis-open.org, wsrp@lists.oasis-open.org
>                       lage.com>                cc:
>
>                                                Subject:  RE:
> [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec
>                       05/23/2002 12:58          0.43]Pers      istent
> Information Scope
>                       AM
>
>
>
>
>
> In the interest of sanity and progress, I have broken up Rich's, Michael's,
> Monica's and Eilon's emails into four subjects - "Shared Transient
> Information", "Persistent Information Scope",
> "createEntity/createTemplate/createPortlet", "session and entity handles",
> and "Property lists".
>
> This email will deal with Persisent Information Scope, and the relevant
> quotes from the emails and my reply to them:
>
> Michael wrote:
> > 2) I think the specification should recognize the per consumer scope. I
> > understand a producer will be able to manage this scope transparently
> once we
> > add a registration handle but I don't think that just because it can be
> > inferred from the model we should ignore it (from the spec/description).
> > 3) The definition of the "persistent information" type needs to be
> tightened.
> > As written it implies a relationship with User transient information as
> both
> > are claimed to be scoped to a user. Whereas a session is scoped
> one-to-one to
> > a user I don't believe persistent information is scoped one-to-one to a
> user.
> > Rather I believe we have discussed situations where the mapping is 1 to
> N.
> > I.e. the producer may be asked to operate on the sample persistent entity
> for
> > differing concurrent user (sessions). This seems to imply that the scope
> of
> > "persistent information" is whatever the consumer chooses it to be.
>
> So now Gil writes:
> I definitely agree on point #3. What I said was actually one Usage of the
> persistent information (i.e. one use is to tie it to the user), but yours
> is actually the more general - "the scope of 'persistent information' is
> whatever the Consumer chooses it to be."
> Objections, anybody? If not, I will change the draft spec appropriately.
>
> I am unclear about Point #2 above. When you're saying the specification
> should recognize the "per Consumer scope", you are talking about the scope
> on what type of information (user transient, shared transient, or
> persistent)? If it doesn't correlate to any type of information and is more
> of a general comment, then can you please elaborate? (e.g. an example, a
> proposed change to the spec)
>
> ----------------------------------------------------------------
> 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