|
(13:32:38) Sam: so no one has as yet
addressed how this filtering stuff is supposed to mesh with the
existing Topic Apis (13:33:17) Sam: maybe I am slow here, but I don't see how that is going to happen (13:33:31) Sam: and if it is not going to happen I would like that explicitly stated 13:37 14:27 (14:27:25) Ian: the existing Topic APIs don't lend themselves well to XPath 14:27 (14:27:39) Ian: ie - non-simple topicexprs (14:28:06) Sam: but you could always have a underlying xml document (14:28:11) Sam: that shouldn't be hard (14:28:31) Sam: essentially the same thing you do for RPs (14:28:37) Ian: i think it's a bit tricky (14:29:03) Ian: so say i call notify on a /xxx:sports/tennis Topic (14:29:12) Sam: right (14:29:31) Ian: and I have a Subscription for /xxx:/sports/* (14:29:51) Sam: right (14:30:15) Ian: when I received the subscribe() request, I do an XPath eval of that expr agaianst my TopicSpaces (14:30:35) Sam: and you get back a nodeset (14:30:52) Ian: and get back three DOM Nodes: /xxx:sports/tennis, /xxx:sports/bball, and /xxx:sports/soccer (14:31:12) Sam: you can translate that nodeset into topic objects within the TopicExpressionEvaluator structure (14:31:31) Ian: so when notify is called, I need to find the intersection of that topic and thiose three (14:31:47) Sam: no, that is not how our stuff works (14:32:11) Sam: when you subscribe you evaluate the topic _expression_ over the topiclist (14:32:30) Sam: you get back a set of topic objects 14:32 (14:32:54) Sam: now for the subscription you register a listener with each of these topic objects (14:33:11) Sam: the listener is called when someone calls notify on the topic (14:33:27) Sam: and ties that notify to the subscription (14:33:43) Ian: so do you see each Topic as holding a reference to a DOM node? (14:33:57) Sam: it doesn't necessarily (14:34:09) Sam: but potentially yes (14:34:22) Sam: if you wanted to implement things like message compliance checking (14:35:24) Ian: so i guess what i'm confused abvout is how the TopicSet would be built up (14:35:45) Sam: so right now the standard topic expressions certainly do not have the complexity of full xpath (14:35:48) Ian: let's say i have 3 topicspaces as xml that i want to expose (14:36:07) Ian: how do i build a TopicSet from them? (14:36:15) Sam: one thing you could do is generate the code to instantiate these topic objects based on a topicspace document (14:36:46) Ian: ok, so i do that. (14:36:54) Sam: a topicset just holds a list of Topics that are root topics (14:37:19) Sam: so in this case you would add three topic objects that correspond to the three topicspaces 14:37 (14:37:44) Sam: each topic can has a list of child topics (14:38:23) Ian: then i have my TopicSet, in order to leverage xpath though i think i'd have to store the DOM Node for each Topic as well as store the DOM for the entire TopicSpace (14:38:29) Sam: you create further topic objects depending on the structure of your topicspace and add them where appropriate (14:39:09) Sam: well you don't really have to have separate objects for those (14:39:30) Sam: the topic objects could just ref a node object that is part of the overall dom document (14:39:49) Ian: either that or i'd need to transfrom each Node in the result NodeSet into a Topic which seems highly inefficient (14:41:02) Sam: you'd have to do that, but it would not be that inefficient (14:41:14) Sam: it's generally the selection that costly (14:41:22) Sam: that's (14:41:22) Ian: but i wouldn't have to do it if each Topic stored a DOM Node (14:42:11) Ian: then when notify() is called on MyTopic i could just see if MyTopic's DOM Node was in the NodeSet for any of its Subscriptions 14:42 (14:42:50) Sam: what is it in this case? (14:42:52) Sam: the NP? (14:43:30) Ian: NP? (14:43:37) Sam: notification producer (14:44:04) Ian: don't underdtand your ques (14:44:26) Sam: "for any of its Subscriptions" -> what is it? (14:44:55) Ian: MyTopic's subscriptions (14:45:05) Ian: ie - your listener API (14:45:25) Sam: I may have lost you somewhere (14:45:30) Ian: yeah i just lost myself (14:46:04) Ian: i guess that would happen at subscribe() time (14:46:08) Sam: yes (14:46:20) Sam: it only happens once (14:46:50) Ian: so i evlauate the TopicExpr against my TopicSet, which evaluates the xpath against its stored DOM (14:47:01) Ian: but then it gets back a NodeSet. (14:47:07) Sam: right 14:47 (14:47:42) Sam: you extract the path for each node and get the corresponding topic (14:47:44) Ian: then how does it transform those Nodes into Topics? (14:48:13) Sam: there is a call for getting the topic for a given path (14:48:45) Ian: and you're saying that call's not expensive? (14:48:53) Sam: yes (14:49:11) Sam: how are you going to deal with aliasing and XPath btw? (14:49:18) Sam: seems like that wouldn't work (14:49:58) Ian: i think it might work if all the topicspaces were crammed into one big DOM (14:50:21) Sam: (I may not be using the correct word here, but you know how you can import parts of another topicspace ) (14:51:05) Sam: unless I am forgetting something you'd almost have to make xpath aware of that mechanism (14:51:11) Ian: i was thinking via an xsd element ref (14:51:43) Sam: so you won't be using the syntax defined in the topics doc for modeling topispaces? (14:51:48) Ian: i'm assuming the underlying DOM would not be of type TOpicSpace but would be something the xpaths could be applied against. (14:51:50) Ian: ie: (14:52:30) Ian: <sportsnews:sports xmlns:sportnews="http://sportsnews.com/"> <tennis /> <basketball /> </sportsnews:sports> 14:52 (14:53:15) Ian: and perhaps it could be changed so that the subelements also have the root topic's namespace (14:53:24) Ian: then you could do something like: (14:53:48) Ian: <sports xmlns="http://sportsnews.com/"> (14:53:54) Ian: <tennis /> (14:53:59) Ian: <bball /> (14:54:32) Sam: hmm (14:54:33) Ian: <otherns:soccer /> (14:54:37) Ian: </sports> (14:54:48) Sam: could you model our topic objects as XMLBeans? (14:54:57) Sam: and build the document that way? (14:55:25) Sam: (sorry if that is a stupid question, still a XMLBeans ignoramus) (14:55:29) Ian: your topic objects pretty much mirror the TopicSpace/Topic types as defined by the spec schema (14:55:55) Ian: if we generated xmlbeans they'd look very simliar to your interfaces (14:56:02) Sam: nod (14:56:24) Ian: but there's no way to tell the xmlbeans compiler to make the xmlbeans implement a predefined interface (14:56:52) Ian: so we'd end up making a facade over xmlbeans (14:56:59) Ian: which i'm not sure would but us much (14:57:15) Ian: we'd need DOM to evlauate the XPaths (14:57:38) Sam: right 14:57 (14:58:11) Ian: do u agree though that the underlying XML sghould be transformed to a form that the xpaths can be applied against? (14:58:23) Ian: ie - option 3) from my email? (14:59:09) Sam: let's put it this way: I don't mind, but I am not sure it is necessary either: Do you really think it will buy you much ease from a implementation perspective? (14:59:38) Ian: well, yes, otherwise i woul;dn't be able to use XPath (14:59:58) Sam: for example I would think that implementing the 3 standard topicexpressions defined in the specs should be really easy with our existing interfaces (15:00:15) Sam: where does the requirement to do XPath topic expressions come from? (15:00:52) Ian: well, i guess mainly from a performance perspective (15:00:58) Ian: it's not a requirement though (15:01:16) Sam: I am not sure that you gain anything by going to XPath for performance (15:01:54) Ian: well, you might in the case of something like YFilter (15:02:04) Sam: since the topicexpressions are generally simpler evaluating them over the current structure should not be very expensive (15:02:22) Ian: that caches/reuses results of previously evaluated expressions 15:02 (15:02:43) Ian: you're right (15:02:56) Ian: i'd expect they'd typically only be 2 or 3 levels deep (15:03:02) Sam: ok, but even if it turns out to be faster it is only a onetime cost for each subscription (15:03:03) Sam: right (15:03:37) Ian: ok, i buy it. (15:03:44) Sam: I do think using Yfilter for filtering a notification stream is a great idea btw (15:04:11) Ian: well, then perhaps we can use it for the Selector (15:04:19) Sam: but that is somewhat of a different problem than this (15:04:21) Sam: exactly (15:04:41) Ian: ok, we'll stick w/ your Topic APIs (15:04:50) Ian: another issue (15:04:56) Sam: so if I were to use YFilter with Topics I would make the stream one of NotificationMessages and filter on the topic element (15:05:06) Sam: but that is a completely different approach (15:05:33) Ian: your Subscription interface currently has several fields that are Axis types (15:05:48) Ian: eg - QueryExpressionType, TopicExpressionType (15:06:02) Ian: we're thinking to change these to be interfaces (15:06:10) Sam: and in that case I would use something to translate topic expressions into a set of XPath expressions to be applied on the stream (15:06:11) Ian: is that ok w/ you? (15:06:11) Sam: anyway (15:06:13) Sam: yes (15:06:16) Sam: definitely (15:06:29) Ian: then we'd have XMLBeans impls (15:06:48) ***Sam nods (15:06:55) Ian: ok, cool. (15:07:23) Ian: what do you think of the pubsub (ie - shared) interfaces? (15:07:34) Ian: i'm questioning if they really buy us anything 15:07 (15:07:56) Sam: yea, that's pretty much my concern as well (15:07:56) Ian: they demonstrate that the two specs are very similar but everyone already knows that (15:08:16) Sam: yup (15:08:26) Ian: my original thought had been that perhaps we could share certain impl classes between the two where it made sense (15:08:28) Sam: I'm not sure I care enough (15:08:52) Sam: if Stefan wants to do this he can, but I agree on it not buying much (15:09:22) Ian: ok, we're on the same page then i think (15:09:29) Sam: cool |
