Re: [wsrp] Leasing questions

[Subbu Allamaraju <subbu@bea.com>]

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 
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
>
>