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