(15:15:53) *ips:* (15:08:30) ips: so WSN subscribe returns the EPR of a Subscription
(15:15:53) *ips:* (15:08:49) ips: and WS-E subscribe returns the EPR of a SubscriptionManager
(15:15:53) *ips:* (15:09:18) ips: for WSN, this EPR represents a WS-Resource
(15:15:53) *ips:* (15:09:27) ips: for WS-E, it may or may not.
(15:15:53) *ips:* (15:09:41) lischke: thats a good proposal i think
(15:15:53) *ips:* (15:09:50) ips: i think what Sam was getting at is that since it's a WS-Resource
(15:15:53) *ips:* (15:10:15) ips: the Globus impl uses a SubscriptionResourceHome to look it up
(15:15:53) *ips:* (15:11:04) ips: in the Globus impl (and in Apollo) each type of Resource (ie - each endpoint URL) has a REsourceHome that is used for lookup/instantiation of resource instances
(15:15:53) *ips:* 15:11
(15:15:53) *ips:* (15:12:00) ips: so hence i think he's saying SubscriptionResourceHome would do the job of your SubscriptionManager interface
(15:15:53) *ips:* (15:12:15) ips: but i'm not sure..
(15:15:53) *ips:* (15:12:34) lischke: lemme take a look at globus SubscriptionResourceHome
(15:15:53) *ips:* (15:12:39) ips: i think we could have a Home for WSN subscriptions and another for WS-E SubscriptionManagers
(15:15:53) *ips:* (15:13:24) ips: and both of those delegate to a SubscriptionStore singleton for storing and looking up subscriptions
(15:15:53) *ips:* (15:13:32) ips: i dunno.. something like that
(15:15:53) *ips:* (15:13:54) ips: i think it'll help once we do a bit of prototyping
(15:15:53) *ips:* (15:14:59) ips: in any case, it will make things easier if we assume the WS-E subscription manager is a WS-Resource, even though the spec doesn't require it to be
(15:15:53) *ips:* (15:15:18) ips: then WS-E can be implemented very similarly to WSN
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
