Comments inline: On Fri, 2005-01-14 at 23:35 -0500, Ian Springer wrote: > (14:23:02) ips: what do u think of renaming SubscriptionManager to > Subscription ? > (14:23:20) ips: since it represents a single subscription > (14:23:41) lischke: :-) in my impl Subscription implements > SubscriptionManager, so i would like to see that on the API too > (14:23:53) ips: ok, let's change then > (14:23:57) ips: makes it more inutitive > (14:24:11) lischke: + > (14:24:13) lischke: 1 > (14:24:24) ips: to me, the name subscriptionmanager implies a class that > manages multiple subs > (14:24:43) ips: will methods be added to TopicFilter and XPathFilter? > (14:25:08) lischke: i dunno i just added them.... > (14:25:44) lischke: maybe in future > (14:26:19) lischke: you changed SubscriptionManager->Subscription or me? > (14:28:28) lischke: things to discuss: callback methods deliver() and > end() and the parameters...... sam wants to put subscriptionpolicy in > subscribe method too, but i cannot model that in wse... i think the > Filter is enough
On the policy front: I believe that there are some arguments that will for the time being have to be ignored by eventing. > (15:16:50) ips: i'm curious why were the fields in Status split out into > another object instead of putting them in Subscription? For extensibility reasons mostly. Both the rp document and the eventing get status reply are open content so I figured it would be good to have another factory like method here. > (15:52:31) lischke: can we change subscribe(....filter[]...) to > subscribe(... filter...) and allow filter to have subfilters? then we > have one filter, which may contain a selector, precondition and maybe a > subscriptionpolicy > (15:53:09) lischke: so filter contains array of filter > (15:53:16) ips: sounds good to me > (15:53:59) ips: can we change dialect from String to java.net.URI? > (15:57:40) lischke: yeah and maybe change name :-) cause it conflicts > with wse FilterType which has also getDialect :-) > (15:57:59) lischke: maybe getURI ? > (15:58:32) lischke: but name changing is not that importand > (16:12:10) lischke: if we change filter[] to filter and make a bigger > filter concept out of it containing selector, precondition ..... then we > should change Status and only do get/setFilter() instead of get/set all > selector..... > (16:13:02) lischke: maybe you are right, and Subscription should be > derived from Status > (16:33:23) ips: i think we should stick w/ an array of filters > (16:33:55) scamp: tsk tsk they didn't lock down their dirs! > http://saturn.jpl.nasa.gov/multimedia/videos/movies/ > (16:34:04) ips: precondition and selector are defined by basenotif > (16:34:26) ips: so they really have nothing to do w/ topicexpression > (16:34:32) ips: just another form of filter > (16:35:41) ips: they prolly don't need to be in the pubsub interfaces at > all > (16:35:53) ips: since they're WSN-specific I suggested Filter[] because even from a message modeling pov WS-BaseN is headed down that path (I suspect there will be a action item during the next f2f for combing both selector, precondition and topic expression into a number of filter elements). A few more thoughts: * On the subscription store front I really do not see the need to invent a new API. What is wrong with the resource home concept/APIs? I also don't see why we can't just have one big subscription home? * Evaluating filters: I would rather leave this up to the 2 different implementations rather than trying to come up with a common API (which is definitely going to clash with our existing WS-N APIs). In general the problem seems to me one of how you view your subscriptions working. The two approaches I see are: 1) You have a single stream per producing resource to which you continuously apply filters 2) You subdivide you stream into a hierarchy of streams (in some sense these are server defined filters rather than client defined filters) and then apply the client provided filters to the substreams. WS-E has imo chosen 1 and WS-N has chosen 2. While you could also model 2 as 1 I think it makes more sense to model 2 somewhat differently (since the number of predefined filters is somewhat fixed you can explicitly model them). In conculsion, I do not think you can come up with a common API if you want to explicitly model 2 which is what we chose to do for WS-N. Hmm, on the other hand you can come up with a API for filtering streams and apply it to the big stream in 1 as well as the substreams in 2. It would mean treating some filters (topics) in the subscription API differently from other filters though, but maybe that is acceptable? /Sam > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Sam Meder <[EMAIL PROTECTED]> The Globus Alliance - University of Chicago 630-252-1752 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
