(14:13:38) lischke: bingo api from sam and me commited (14:13:46) lischke: just for starting (14:13:48) ips: cool (14:13:59) scamp: hey what UML proggie did you use? (14:14:11) lischke: i'll commit org.apache.ws.eventing next minutes/hours (14:14:20) lischke: scamp: i use together 6.0 (14:14:32) scamp: ok (14:14:42) lischke: from borland, really nice designing and coding on the fly.. changing dia changes code and vice versa (14:15:09) lischke: on sequence dias just press generate code, and on code you can generate seq dias (14:15:16) scamp: yeah i've used it in the past (14:16:12) lischke: ips: maybe some other good news, we maybe can work together with another ws-eventing impl to test interop (14:16:26) ips: the MS one? (14:17:08) lischke: ips: thats the really funny, MS doesnt seem to have one, its the plumbwork orange project... from guys working at/for MS... its open source (14:17:18) lischke: but you are right its using .Net (14:17:30) ips: cool (14:17:48) ips: does it implement client as well as server? (14:18:38) lischke: yeah think so (14:18:45) lischke: i'll forward MS mail to ML (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 (15:16:50) ips: i'm curious why were the fields in Status split out into another object instead of putting them in Subscription? (15:17:44) lischke: should there be a request everytime a get method is called? (15:19:24) lischke: unsubscribe() / cancel() naming is not that important, once all are working on hermes, we could start a vote and just make a string replacement in all the code (15:20:19) ips: what these interfaces look like won't affect how many SOAP messages need to be sent (15:20:25) ips: the spec WSDLs dictate that (15:22:19) scamp: I agress with lischke...lets not get hung up on that stuff for now (15:22:57) lischke: yeah but what i mean is, with GetStatus() you really start getResourceProperties/GetStatus Request (15:23:14) lischke: when putting it in subscription (15:23:41) lischke: then you dont know if a request was started and maybe local data was given back (15:28:38) lischke: in my impl eventing.Subscription implements Subscription and Status Interfaces (15:28:56) lischke: and getStatus returns "this" :-) (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 (16:55:23) scamp left the room (quit: ). (17:31:18) ips: liscke: shouldn't the Filter interface have some sort of apply() method? (17:35:07) lischke: why? filtering is not done by brute force applying all filters one by one.... in my impl for example i use yfilter to do paralell filtering (17:35:20) lischke: and the user doesnt need to filter or am i wrong (17:35:54) ips: i'm just trying to understand how the runtime will work (17:36:07) ips: a notif occurs. (17:36:41) ips: now i need to see what subscriptions have filters that return true for that notif (17:37:15) ips: i was thinking the runtime would call an apply() method on each of the filters in each subscription (17:37:52) ips: could do so in parallel of course (17:39:20) lischke: hmm (17:39:36) lischke: that should be implementation specific maybe and not reflected in the API (17:40:02) lischke: in my impl i call apply on the subscriptionStore (17:40:37) ips: so how is the Filter interface used at runtime? (17:40:57) lischke: i think only for creation of subscription (17:41:15) lischke: and of cause at the publisher side (17:42:31) ips: hmm, not sure i fully grok yet (17:42:44) ips: i'll look at your impls when u check em in (17:42:54) lischke: you looked at my sequence diagram? (17:43:06) ips: not the latest (17:43:09) ips: lemme look at that (17:43:15) lischke: at my blog (17:46:55) lischke: there you can see, that the publisher has to handle the subscribe call from the web service framework (17:47:13) lischke: filtering is left open in our API (17:47:42) lischke: but we can add tools for that, like a subscriptionStore, where one can add filters and also call apply() (17:51:37) ips: hmm (17:52:30) ips: i don't see the point of passing around Filters if they're not really ever used/applied (17:52:47) ips: why not have a (17:53:30) ips: boolean apply( Object notif ) method ? (17:53:59) lischke: which will return a boolean (17:54:18) lischke: ? (17:54:45) lischke: sorry :-) (17:54:51) lischke: dont read boolean (17:55:37) lischke: we can do this, but then we force the user to do brute force filtering (17:55:48) ips: how so? (17:56:03) lischke: when is this apply method called? (17:56:21) ips: when a notif occurs (17:56:58) lischke: but thats inside the webservice framework (17:57:22) ips: i mean a backend notif (17:57:42) ips: say something like a hard drive starts spinning (17:57:57) ips: and we want to send a HardDriveStarted notif (17:58:23) lischke: then you first have to create a Publisher for the hardriver (17:58:52) lischke: and give a NotificationProducer to it which handles subscribe requests (17:58:58) ips: i'd picture having a sendNotif method that the developer would call, possibly on the Producer resource (17:59:13) ips: right (17:59:30) lischke: Therefor the Publisher has a NotificationConsumer instance, on which he calls deliver (17:59:32) lischke: right? (18:00:04) ips: not how i was picturing it (18:00:28) ips: he doesn't know who he wants to deliver it to (ie - what subscriptions exist) (18:00:59) ips: i'm picturing the publisher calling deliver() on some SubscriptionStore (18:01:31) lischke: ok, so the SubscriptionStore is implementing Notificationconsumer interface (18:01:33) ips: that then loops through any subscriptions that exist and calls apply on each filter in each of them (18:01:51) ips: to dtermine the list of Consumers that should be sent the notif (18:02:06) lischke: maybe loops or applies in paralell, thats application specific and depends on impl of subscriptionStore (18:02:34) ips: ok (18:02:53) lischke: so filter.apply is in aplication specific domain (18:03:01) ips: i was thinking of a Consumer as a particular endpoint that subscribed (18:03:25) lischke: ahh no (18:03:35) ips: i see you're treating the SubscriptionStore as one big consumer (18:03:35) lischke: maybe thats not good to see in my seq dia (18:03:44) lischke: righty (18:03:51) lischke: meks sense ? (18:03:57) lischke: does it make sense? (18:04:03) ips: yes better (18:04:18) ips: though still unclear why Filter would not have an apply method (18:04:43) lischke: :-) we can add it first and maybe look in some weeks if we still need it ok? (18:04:49) ips: i guess you're saying you wouldn't be able to implement it that way if YFilter is the backend (18:05:07) lischke: y (18:05:28) lischke: or better, when yfilter is used i dont need apply() (18:07:07) lischke: btw: can you save this discussion and post it to me or the ML? just for reference (18:07:46) ips: sure (18:08:18) ips: ok, so why does consumer have getEPR()? (18:08:53) ips: in the subscriptionstore case, it would not have a single EPR right? (18:09:19) lischke: right (18:09:41) lischke: but on the subscriber side (18:09:42) lischke: hmm (18:09:49) ips: or is it the EPR of the producer? (18:11:21) lischke: on the subscriber side its the EPR of the consumer, and maybe you are right on the publisher side its the EPR of the producer (18:13:32) lischke: but im not sure .. have to think more (18:13:55) ips: hmm, that's not very intuitive (18:14:25) ips: also why does deliver take a filter and an epr? (18:14:51) ips: i'd think that those would be already stored in the subscription store (18:15:21) lischke: deliver and end parameters have to be discussed, you are right, that was only an idea (18:15:23) ips: even on the consumer side, i don't think they'd be needed (18:16:21) ips: they would have already specified them in the subscribe request (18:16:37) lischke: on the consumer side the filter may be important, to see whats the message about, when one uses one Consumer Impl for many Subscriptions (18:17:35) lischke: for example a broker, does only use one Consumer Impl class, which itself has a subscriptionStore where he forwards the messages to (18:18:15) ips: hmm.. even if there are many subscriptions, each of those subscriptions would already contain a set of filters (18:20:47) lischke: but deliver dont has a Subscription parameter (18:20:58) lischke: it only gets the message (18:22:31) ips: right, but my thought was that the set of subscriptions would be a field of the object (18:22:47) lischke: ok let me think (18:22:53) ips: for the subscription store (18:24:09) lischke: hmm i dont get it, you mean the object parameter on deliver ? (18:27:46) ips: no i just mean if it's s subscription store, it's gonna contain all the subscriptions as fields (18:28:00) ips: the publisher would only need to pass the notif msg itself to deliver() (18:28:06) lischke: right (18:28:13) lischke: but its different to subscriber side (18:28:25) lischke: thats a problem (18:28:33) ips: the subscription store would have all the info it needs to actually send the notifs out to the appropirate EPRs (18:28:44) lischke: right (18:29:36) lischke: but on the subscriber side more information(to which subscription it belongs) is needed about that message (18:30:29) ips: why would deliver() even be used on the subscriber side? (18:31:14) lischke: when creating a subscription, you give an impl of notificationconsumer interface... and deliver is called on this impl when there is a notif for that subscription (18:31:16) lischke: right? (18:31:47) lischke: that was our callback apporach (18:31:59) ips: ok, yes (18:32:29) lischke: hmm deliver is really a problem and end() maybe too (18:33:18) ips: i think it would simplify to not make the subStore implement NotifConsumer (18:33:39) ips: subStore's deliver would then simply take the message as a param (18:34:08) ips: and we could have one subStore per producer (18:34:51) lischke: thats breaking up our "one API on both sides" approach, but its a solution (18:35:16) ips: maybe not (18:36:14) lischke: is subsStore still implementing notificationproducer? (18:36:40) ips: the one API is more meant for server-side things that would need stubs on the client-side (18:37:05) lischke: ok (18:37:11) ips: but notiConsumer as defined by the spec is really just a callback URL that's one of the params passed to a sub (18:37:49) ips: it's not a stub of any particular server-side object (18:38:21) ips: there's one consumer per subscription (18:38:37) ips: but one subStore per producer (18:39:03) lischke: ok i'm convinced, so lets create a SubscriptionStore Interface (18:39:22) ips: k (18:39:43) ips: is one subStore per producer what u were also thinking? (18:39:55) lischke: of cause (18:39:58) ips: as opposed to one huge subStore (18:40:01) ips: cool (18:40:18) lischke: wait :-) (18:40:34) lischke: you mean one producer=1 subscription? (18:40:53) ips: no. 1 producer = one subStore (18:41:09) lischke: ok (18:41:17) lischke: :-) (18:41:25) ips: and subStore containsall subscriptions for that producer (18:41:40) lischke: right and is implementing notificationproducer interface (18:41:57) ips: hmm (18:42:00) lischke: :-) (18:42:20) lischke: maybe not (18:42:34) ips: right probably but not necessarily (18:43:03) ips: in other words don't make the subStore intf extend NotifProducer (18:43:10) ips: leave that to the impl (18:43:32) lischke: ok, so the impl can decide to put the subsriptions to the store (18:43:52) lischke: or not (18:44:50) ips: well, i could go either way now that i ponder it more (18:45:14) ips: i mean the store's gonna need to be passed the subscription params eventually anyway so it can store them :) (18:46:24) ips: i think we can add a getEPR() method to NotificationProducer that return the producer's EPR (18:46:52) ips: and then remove the first param from its subscribe() method (18:47:14) lischke: lemme think (18:48:12) lischke: righty (18:48:19) lischke: that makes more sense on the client side (18:48:40) lischke: then we really have one notification producer for one endpoint (18:49:25) ips: right (18:49:55) ips: which is closer to the spec (18:50:49) lischke: but i have problems thinking of a way how to tell the web service framework which notificationproducer to use on the publisher side..... maybe a factory (18:51:07) dims: looks like u guys are making good progress :) (18:51:23) lischke: we hope so :-) (18:51:28) ips: hehhe (18:52:27) ips: even if we add a SubscriptionStore interface (18:52:44) ips: i think we could still leverage NotificationConsumer on the server side (18:53:28) lischke: yes (18:53:54) ips: when deliver( Object msg ) gets called on the subStore by a publisher (18:53:56) lischke: when a filter matches it calls the notificationconsumer of that subscription, which sends itself to the subscriber right? (18:54:31) ips: yes, exactly (18:54:47) lischke: thts my forwardingConsumer on my Broker (18:56:25) ips: btw, let's generally avoid putting setters in interfaces
(18:56:39) ips: except for fields that are mutable
(18:56:56) lischke: .
(18:57:03) ips: the impls can always have setters
(18:57:35) lischke: something other: when an application wants to be a
publisher, what does it do?
(18:58:20) lischke: it uses some kind of notificationProducerFactory to
which it gives a notificationProducerImpl ?
(18:58:36) ips: yeah we have to think bout that
(18:59:39) ips: i think you'd the serverside Resource object would
implement NotifProducer
(19:00:18) ips: as well as a NotifCallback interface
(19:00:58) lischke: why the notifcallback interface?
(19:01:44) ips: scratch the callback if
(19:02:37) ips: basically the backend representation of that resource
would need to have a reference to the producer resource object then
simply call deliver when it wants ro emit o notif
(19:03:47) ips: the ref to the resource object might need to be RMI if
the backend object's not in the same JVM
(19:30:02) lischke: you know why might be the "object" of the deliver()
method? a SOAPEnvelope?
(19:34:52) lischke: its a question if the SOAPHeader is needed.....
(19:39:39) lischke: 2) notificationConsumer needs 2 Epr's cause of
notifyTO and endTo ;-(
(19:46:26) lischke: 3) maybe it is better to have deliver(Subscription
s, Object msg) in the notificationconsumer callback interface
(19:46:46) lischke: 4) if 3) then we also need a SubscriptionStore on
the Subscriber side
(19:56:47) lischke: 5) 2) is very !!! important :-)
(20:53:05) ips: i think the Object passed to deliver would be just the actual notif msg
(20:53:11) ips: not the whole envelope
(20:53:28) lischke: then the subscriptionID has to be in the EPR
(20:53:44) lischke: in the resourceProperty
(20:53:54) ips: the NotifyTo and endTo could be obtained from each Subscription
(20:54:20) ips: and the SOAP headers cvould be built up using those
(20:54:55) ips: subscription id would also be in the stored subscriptions right?
(20:55:20) lischke: we could do that
(20:55:39) ips: oh yeah guess it's not now
(20:55:58) lischke: so deliver would look like deliver(Subscripition, message)
(20:55:58) ips: by ID you mean the EPR of the SubscriptionManager right?
(20:56:03) lischke: yes
(20:56:41) ips: yes, on NotifConsumer
(20:56:49) lischke: right
(20:57:00) ips: but on SubscriptionStore, i think it would just be deliver( message )
(20:57:01) lischke: now to point 2)
(20:57:11) lischke: substore: right
(20:57:18) ips: ok
(20:57:39) lischke: when you call getEPR on notifCons what you get
(20:57:47) lischke: EPR of notifyTO or endTO
(20:57:54) lischke: -> problem
(20:57:55) ips: yeah
(20:58:00) ips: might not be the same
(20:58:17) lischke: must be getNotifyTOEPR and getendtoEPR
(20:58:43) lischke: or we split up notifcons into notifcons and notifendcons
(20:59:01) ips: hmmm
(20:59:09) ips: endTo is optional right?
(20:59:21) lischke: in wse not
(20:59:24) lischke: but in wsn
(20:59:45) ips: wsn doesn't have endTo at all does it?
(21:00:14) lischke: it has an endTo (destroy notification on WS-ResourceLifetime)
(21:00:39) lischke: or it could have one modelled with ws-rlft
(21:01:05) lischke: its on the usecase dia i posted
(21:01:30) lischke: its very useful for example if publisher goes down
(21:02:29) ips: yeah, i suppose but it would be done via a separate subscription request
(21:02:47) ips: whereas in wse it's done in the same subscribe request
(21:03:17) ips: just checked - EndTo is optional in a WS-E subscribe request
(21:03:38) ips: if not specified, no endTo notifs are sent
(21:04:00) lischke: so you think of killing it?
(21:04:20) ips: no, just thinking we don't need an object for it
(21:04:37) ips: just add a getEndToEPR() method to Subscription
(21:04:42) ips: and to subscribe()
(21:05:03) ips: and if there is no endTo, return null
(21:05:40) ips: only thing is i'm not sure how well that maps to WSN
(21:06:47) lischke: and then we have 2 getEPR's in notifconsumer
(21:07:22) ips: not sure we'd need it
(21:08:15) ips: consumer represents where the actual events being subscribed to are sent
(21:08:25) ips: not endTo events
(21:09:22) lischke: right.. like in my first design i had 2 callback interfaces
(21:09:38) lischke: but then i prolly merged them
(21:11:06) lischke: lets talk about that next time, what about 4)
(21:11:33) lischke: if we have deliver(Subscription, message) we also need a subscriptionStore on the subscriber side
(21:12:36) lischke: the notif request contains only subscriptionID, and then the substore must look it up and give the right subscription to the callback deliver(..)
(21:13:21) ips: thinking..
(21:16:07) ips: would the callback even need the Subscription for anything?
(21:21:13) lischke: :-)
(21:21:35) ips: but i see your point
(21:22:43) lischke: hey ian, let me think again tomorrow, i'm really tired, it is half past 3 in the morning here in berlin :-)
(21:23:04) ips: sure, no prob. i'm fried too
(21:23:47) ips: we'll ponder it some more and come up with something good
(21:24:15) lischke: i'm finishing my strawman of eventing tomorrow, and setting up a broker on my server here at the university
(21:24:45) ips: cool, look forward to checking it out
(21:24:47) lischke: then i'm going to contact john bristowe from plumbwork orange and the M$ guys
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
