Steve Graham wrote:
so, if you want to figure out what
filter
was used that allowed the message to be
produced/delivered/sent/whatever_verb
dereference the subscription EPR and examine the metadata associated
with
the Subscription. Although you could do this to figure out topic
informatoin too, it is slightly less obvious, in certain cases, if the
topic filter is specified and it is /*/, it is useful to know which
topic(s) the message was published on.
The issue is analogous to what Sanjay pointed out for Topics. A filter
specification might want some sort of "why you're getting this message"
element included in Notifications. For example, if your original
filter was something like "State = Kansas OR Sport = Basketball", the
Notification would contain "State = Kansas", "Sport = Basketball" or
both, depending on what matched. This is not the same as knowing the
original filter.
Fortunately, in issue 2.47 we agree to add open content to Notify, so
this sort of thing is allowed (duh, perhaps I should have re-read the
issues list first :-), and in 2.51 we agree to allow for the equivalent
in raw messages.
So the only remaining question is whether this behavior with respect to
topics should be defined in the core or moved out to topics. On the
"eat your own dog food" principle of extensibility, I would prefer that
it be moved, as this would make it clear that the framework is
extensible and provide guidance as to how future extensions should
look, but I'm not going to lie down in the road about it.
sgg
++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, IBM Software Group, Web services and SOA
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++
Steve Graham wrote:
I thought we agreed to make the topics component optional in the Notify.
Right ... so you can leave that out if you want. The
question is, can you put anything else in if you want? I had thought
there was open content, but there doesn't seem to be.
The other question is to what extent the core needs to talk about
topics
at all, or if you prefer, to what extent are topics "just another
filter"?
++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, IBM Software Group, Web services and SOA
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++
Steve Graham wrote:
+1 to Sanjay.
We had the notion of filter previously (we called it selector) but did
not choose to add it to the "metadata" in the Notify message.
I don't see that anything has changed to compel us to rethink this
bit.
So what's so special about topics? Also, wasn't that decision taken
prior to making topics optional?
sgg
++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, IBM Software Group, Web services and SOA
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++
"Patil, Sanjay" <sanjay.patil@sap.com>
wrote on 05/26/2005 04:20:40 PM:
>
> Filters are part of Subscribe message, where as Topic is a Notify
> metadata. I don't see the connection.
>
> Thanks,
> Sanjay
>
> >-----Original Message-----
> >From: David Hull [mailto:dmh@tibco.com]
> >Sent: Thursday, May 26, 2005 13:17 PM
> >To: wsn@lists.oasis-open.org
> >Subject: [wsn] Topic/filter metadata in Notify message
> >
> >
> >The Notify message (actually, the metadata that may be used
with
either
> >Notify or raw delivery) includes a "Topic" element.
Should
> >this not now
> >be a "Filter" element?
> >
> >
|