Subject: [Tools-team] A way to think about events: xml publish/subscribe

From: Bill Fenner <[email-masked]>
Date: Wed, 9 Feb 2005 12:00:42 -0800

In some other work, I've been talking with others here about the
publish-subscribe model, which is basically best summarized as a
constantly-running query run over a changing set of data.

I think this model is a decent way to think about the event
notification work and that is where some of the discussion of
"it's like a search engine" vs "it's queries for new drafts"
etc. comes from - in this model, it *is* like a search engine,
but the usual usage is to match searches against newly-published
data and it's relatively uncommon (but possible) to use it like
what we think of as search engines now.

There's lots of discussion about how to use XPath or XQuery or etc.
to describe events of interest; this gives much more power than
the existing description, but perhaps too much.  (Unfortunately,
"learn about XQuery" has been on my to do list for months, so
I'm actually not sure what it provides, but even XPath can do
at least some of what we talked about, e.g.,
"//doctag[starts-with(.,'draft-fenner-')]")

  Bill

_______________________________________________
Tools-team mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tools-team

---

From: stanislav shalunov <[email-masked]>
Date: 09 Feb 2005 15:34:11 -0500

Bill,

I like the analogy.  I would also say that what we want is inexpensive
access to a state-thin interface (Google, if you will), not customized
keeping of lots of state (Googlealert, if you will).

We also want to make Googlealert-type things possible, obviously.

One would hope that the approach of building something simple and
well-defined that allows for any bells and whistles to be added by
anyone later would be uncontroversial.

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

Clothes make the man.  Naked people have little or no influence on
society.                                             -- Mark Twain

---

From: "Alex Rousskov" <[email-masked]>
Date: Wed, 09 Feb 2005 17:10:20 -0700

On Wed, 2005/02/09 (MST), <[email-masked]> wrote:

> etc. comes from

I have no problem with the analogy, but the above discussion is not what I  
was trying to discuss. The point I am trying to make is that there are  
several distinct components here:

   - events
     (what an event is)
   - subscriptions
     (what a subscription is, how to create a subscription record, etc.)
   - event generation sources
     (things that generate events)
   - event sinks
     (things that receive events)
   - event/subscription matching algorithm
     (does subscription record X match event Y?)
   - notification service (one of the event sinks)
     (using the matching algorithm to notify subscribers of "their" events,
     whenever an event is received from an event source)
   - event archive (one of the event sinks)
     (permanent storage for new events)
   - an archive search service
     (searching archived events)

While many of the above components are very simple, I think it is  
important to know which one we are discussing at any single point.

> - in this model, it *is* like a search engine,

Agreed. I have to note, however, that the "true" or "traditional" seach  
engine (the last component above) may support queries that differ from  
those that the subscription interface supports. For example, I might want  
to find all events that occured last year, but I cannot subscribe to last  
year events. If there is no significant implementation difference (e.g.,  
both use XQuery), that's fine, but the concepts of subscribing to future  
events and searching through past events are still different, IMO.

Alex.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 11 Feb 2005 09:34:48 +0100

note.... this was extensively discussed in LDAP at one point...
some drafts may still be around that describe various techniques to specify 
queries......