- From: <bugzilla@wiggum.w3.org>
- Date: Mon, 23 Mar 2009 14:32:31 +0000
- To: public-ws-resource-access-notifications@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6724 Summary: Eventing: define resource representation Product: WS-Resource Access Version: FPWD Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Eventing AssignedTo: public-ws-resource-access-notifications@w3.org ReportedBy: dug@us.ibm.com QAContact: public-ws-resource-access-notifications@w3.org WS-Eventing defines a GetStatus() operation to return the current Expires time of the subscription. While this information is useful, its a bit puzzling why this is the only bit of information allowed to be queried. For example, why not allow people to ask for the current filter, delivery or format information? Likewise, why is the Expires time the only property allowed to be updated? If there are properties of a delivery mode that need to be updated, why should someone be forced to unsubscribe and resubscribe just to make this change? Proposal: 1 - Remove GetStatus and Renew operations. 2 - Define a minimum XML represenation of a Subscription Manager resource, which, btw, would look a lot like the Body of the Subscribe. 3 - Mention in WS-Eventing how WS-Transfer can be used to query/update the Subscription Manager's XML representation 4 - Like the GetStatus/Renew operation - the use of Transfer (or even exposing a Subscription Manager as a 'resource') will be totally optional. This will also better align WS-Eventing with the rest/web architecture by clearly defining what is at the Subscription Manager EPR. Side note: Its not clear to me if this same issue should be opened against Enumeration. While it feels like it should, Enum is slightly different in that an Enumeration Context is passed around - meaning that no state needs to be maintained on the server (if it doesn't want to). -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug.
Received on Monday, 23 March 2009 14:32:39 UTC