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] | [List Home]


Subject: Re: [wsrp] Leasing questions


Subbu Allamaraju wrote:

>
> BTW, I asked the original question to simply check the conformance
> points. I don't know what a Producer/Consumer impl would/should do when
> the feature is not supported by some artifacts of the feature show up in
>
Meant to say "not supported _but_ some artifacts".

>
> messages. What you and Andre suggest is definitely possible.
>
> The current wording sounded a bit odd to me. For other features (e.g.
> events), we don't have such wording in the spec, so whatever
> ServiceDescription says about the event feature support would win. So,
> my question is what is the point in the conformance statements for
> Lifetime? IMO, it would be simpler to let ServiceDescription be the only
> place for interpreting whether a feature is supported or not supported.
>
> Subbu
>
> Rich Thompson wrote:
>
> >
> > The conformance language ties two behaviors together, responding with
> > leasing information is bound to supporting the leasing feature. As
> > Andre has said, the Producer could always refuse to update a
> > termination time (i.e. its policy on the termination time is set-once).
> >
> > What would be the value in trying to separate leasing into multiple
> > parts? In particular, would it be worth the additional complexity such
> > a separation would bring?
> >
> > Rich
> >
> >
> > *Subbu Allamaraju <subbu@bea.com>*
> >
> > 07/04/05 09:23 PM
> >
> >      
> > To
> >       wsrp <wsrp@lists.oasis-open.org>
> > cc
> >      
> > Subject
> >       Re: [wsrp] Leasing questions
> >
> >
> >
> >      
> >
> >
> >
> >
> >
> > Let me pose the question differently. Through out the spec, whenever
> > there is a reference to Lifetime structure, there is wording that says
> > that Producers returning this structure MUST support the leasing 
> feature
> > (e.g. see sec 6.1.3).
> >
> > Strictly speaking, when a Producer says via its ServiceDescription that
> > the leasing feature is not supported, what is the purpose of the
> > additional conformance language?
> >
> > Regards,
> > Subbu
> >
> > Andre Kramer wrote:
> >
> > > I would see more value in allowing a producer to declare that its 
> policy
> > > does not allow a consumer to influence (i.e. set) scheduled 
> destruction
> > > times but would leave this to a future "policy" framework, not v2.
> > >
> > > With this, I think the suggested returning lifetime information, even
> > > when a (v1) producer states wsrp:leasing is false seems strange. 
> Would
> > > it not be better to just say wsrp:leasing is true and refuse to 
> accept
> > > any setTerminationTime request (i.e by just leaving the scheduled
> > > destruction time unchanged in the reply)?
> > >
> > > Regards,
> > > Andre
> > >
> > > -----Original Message-----
> > > From: Subbu Allamaraju [mailto:subbu@bea.com]
> > > Sent: 03 July 2005 23:55
> > > To: wsrp
> > > Subject: [wsrp] Leasing questions
> > >
> > > A v1 Producer could impose arbitrary lifetime restrictions on
> > > registrations and cloned portlets, and terminate(from the protocol
> > > sense) those after that lifetime. V1 Consumers cannot be aware of 
> this
> > > lifetime.
> > >
> > > If such a Producer offers to support parts of v2, is it valid for 
> it to
> > > not offer the leasing feature, but express scheduled destruction 
> via the
> > >
> > > Lifetime parameter?
> > >
> > > That is, can the Producer return wsrp:leasing  as false, but still
> > > return Lifetime within PortletContext (e.g. after a pbia) and
> > > RegistrationContext?
> > >
> > > My current understanding of the spec is that this is not valid, and I
> > > see value in allowing this.
> > >
> > > Regards,
> > > Subbu
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe from this mail list, you must leave the OASIS TC that
> > > generates this mail.  You may a link to this group and all your 
> TCs in
> > > OASIS
> > > at:
> > > 
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  You may a link to this group and all your TCs in
> > OASIS
> > at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in 
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>



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