Re: Xquery might have some things right

"Mikito Harakiri" <mikharakiri_at_iahu.com> wrote in message news:MW42c.23$zW4.91_at_news.oracle.com...
> "Corey Brown" <corey_at_spectrumsoftware.net> wrote in message
> news:e242c.47448$0l1.6619_at_bignews3.bellsouth.net...
> >
> > Yes, of course, but what does that have to do with using XML as a
> message
> > protocol for publish and subscribe systems?
>
> I don't see any XML relevance in the context of publish and subscribe
> systems.
>
> A client registers its interest in a certain event that may happen on a
> server. That is formally a rule: if a certain predicate becomes valid, then
> sever have to do some action (e.g. notify a client). That is the area of
> active database systems. Note that client notification is one of the
> possible actions (e.g. I want to sell the stock right away, I don't want to
> be merely notified that the stock price became attractive). There are
> multiple ways to implement notification too, for example, client can
> register remote callback, etc. Anyay, no matter what notification
> implementation is, the content of the message is too small to warrant making
> it XML. Once again, if the client needs more info, it can always query the
> server and this is far superior to any other alternative you may suggest.

    I can tell you haven't done this type of thing very often. What if we're talking     about an entire network of "clients" that need to be notified. Would you send     them some sort of notification and then allow every one of them to then perform     a remote query on your servers local database? Doesn't sound like a very scalable     solution to me? I think the slight amount of overhead introduced by using a wordy     protocol like XML, when combined with a UDP broadcast, is far superior to     the "pull" type system that you are suggesting.

    Regards,
    --Corey
>
>
Received on Sat Mar 06 2004 - 01:31:37 CET