Hi Dan, thanks for the reply. I personally don't need those methods.
I'm an absolute beginner concerning the whole WS-* universe. I started with the WS-N spec and got through it. That's the point where I saw that for the base SubscriptionManager both methods are mandatory. As there are also already some mail threads about this issue I thought it might be useful to settle this by referencing to the spec. As I think it is useful to fulfil the WS-N spec. I will open the Jira item. Concerning the focus of Muse regarding the WSRF: As my focus is on the WS-N implementation, I was wondering why there was so much relationship to the WSRF spec. I think I still don't have a notion on how all those WS-* spec's are correlated to each other. As I wanted to progress with the WS-N implementation, I didn't want to go through the whole WSRF calls and dependencies. But as you said: All WS-N resources are WSRF resources. This is certainly the right way to implement it, but it is new for me and I though that there was from Muse a focus on the WSRF. So I'm still struggling with the relationship between Topic and Resources. As I opened already a thread on this issue, I would like to continue on this thread the issue what I want to achieve. Best regards, Matthias -----Ursprüngliche Nachricht----- Von: Daniel Jemiolo [mailto:[EMAIL PROTECTED] Gesendet: Montag, 19. März 2007 14:11 An: [email protected] Betreff: Re: unsubscribe is a must If you really need unsubscribe() and renew(), just create a JIRA item for them. They are trivial to implement given our current code base, we only left them out because they seemed to duplicate existing WSRF operations (destroy() and setTerminationTime()). In my past experience with the WSN draft specs, unsubscribe() and renew() were defined for the cases where subscriptions were NOT ws-resources and thus, did not have WSRF capabilities. Since everything in Muse IS a ws-resource, and our WSN implementation does build on WSRF, we didn't have that problem. If the ratified standard has introduced a requirement, though, we will do it - but you still have to make a JIRA item. ;) I'm not sure why you think Muse isn't as focused on WSN (WSN certainly took more effort than WSDM). We use it for reporting the notifications defined in the standard, but other than that, it's up to you to package and send your custom notifications. More info here: http://ws.apache.org/muse/docs/2.2.0/manual/how-to/publish-any-notification.html http://ws.apache.org/muse/docs/2.2.0/manual/how-to/publish-wsrp-notifications.html Is there something else you're looking for in the implementation? Perhaps I can point out other features if you describe exactly what you want to achieve. Dan "Beil, Matthias" <[EMAIL PROTECTED]> wrote on 03/19/2007 05:25:22 AM: > Hi, > > > > after reading some mail threads for the unscribe method implementation I > had a look at the spec of WS-N > > > > http://docs.oasis-open.org/wsn/wsn-ws_base_notification-1.3-spec-os.pdf > > > > at the chapter 6. line 1134 they state: > > > > All SubscriptionManagers MUST implement the message exchanges described > in the Base Subscription Manager section. > > > > In the next chapter 6.1 at line 1142 the spec states: > > > > The basic behavior of a SubscriptionManager is to renew the duration of > a Subscription resource and terminate a Subscription. > > > > In the mailing thread there was the suggestion to use the returned > subscription to destroy the subscription, but in my regard the > "unsubscribe" method should be used to adhere to the WS-N spec. > > > > My personal impression after 5 days of using Muse is, that Muse is more > focused on the WSDM and the WSRF capabilities and that the WS-N serves > only as a delivery channel for informing the connected clients of > resource changes. > > > > As my focus is on the WS-N spec. and the workflow defined to exchange > notification, my interest is more in having a complete WS-N > implementation. And from this point of view are there some plans to and > the "renew" and "unsubscribe" methods? > > > > Mit freundlichen Gruessen / With kind regards > > Matthias Beil > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
