[Standards-JIG] Proposed Changes to JEP-60 - PubSub
Fletcher, Boyd C. J9C534
Boyd.Fletcher at je.jfcom.mil
Wed Jun 2 13:41:17 UTC 2004
> -----Original Message-----
> From: standards-jig-bounces at jabber.org
> [mailto:standards-jig-bounces at jabber.org] On Behalf Of Richard Dobson
> Sent: Wednesday, June 02, 2004 4:08 AM
> To: Jabber protocol discussion list
> Subject: Re: [Standards-JIG] Proposed Changes to JEP-60 - PubSub
> >> Please dont think of pub-sub as a stand-alone functionality to be
> >> implemented.
> >> It's a base protocol that you built your desired functionality on.
> >> I don't really see a usage pattern in publishing and
> subscribing to a
> >> pub-sub node directly.
> >> You need to know what kind of data is published and how to use it.
> > then it's a useless protocol because, developers have to
> implement a
> > new custom pubsub service for every new service. That just doesn't
> > make any
> > You should not have to do that. It's a duplication of
> effort and wasteful.
> > If we have a feature complete PubSub specification, a single
> > would be all that is required.
> Huh, of course you wouldnt need to implement a new custom
> pubsub service for each and every new application of pubsub,
> why would you? You making that statement clearly shows you
> dont really understand what pubsub is all about, maybe this
> is a fault in the spec im not sure, but the way I understand
> that pubsub is supposed to work is that the pubsub server
> just acts as a generic datastore (based on this spec), the
> pubsub server does not need to understand any of the higher
> level applications of the pubsub protocol as it doesnt
> examine the data it is given, it just does what it is told at
actually I'm not at all concerned about the data. In order for the PubSub Service to work it has to implement a protocol. The problem is the protocol is TOO VAGUE to be correctly implemented in a consistent manner.
> the generic command level and stores, deletes, modifys,
> distributes etc. The higher level protocols that you need to
> develop on this base protocol are only useful to entities
> that actually want to understand what this stored pubsub data
> is and what it represents, which in the case of user moods
> would be a particular users mood at the time, the pubsub
> server in no way needs to understand this level of info so
> your statement that a new custom pubsub server would be
> needed for each new pubsub application protocol is false and
> >> This functionality is a basis of such new protocols as publishing
> >> avatars, or song information, or headlines events.
> >> There are JEPs for this, that contains these MUSTs you want.
> >> If you limit functionality of the base protocol they use -
> >We are not limiting the functionality of the base protocol. We are
> > enhancing it by specifying how it behaves in a predictable, well
> > manner. So that clients can implement User Moods, Headline news,
> > avatars, etc.... WITHOUT having to have a specific custom PubSub
> > implementation on EVERY server you have an account on.
> As explained above there is no requirement for the pubsub
> server to understand the higher level pubsub application
> protocol, so there is no need for custom implementations of
> the server for each protocol, these higher level protocols
> are only useful to the entities that want to understand the
> pubsub data.
please re-read the specification again. paying particular attention to things like NodeID and ItemID naming and conflict resolution and the lack of a complete subscription/notification behavior definition. All the comments I've made up till now are concern about the creation, deletion, naming, and modification of Nodes and Items. I'm not terribly concerned about what the data is. if the creation, deletion, naming, and modification of Nodes and Items is not sufficiently defined (and its not in the spec), then the data is irrelevant because you will not be able to access it. Where in any of the emails have I mentioned "application specific" level protocols, I haven't. If the core protocol isn't sufficiently robust in its definition, you can't build higher level protocols. I'm ONLY concerned about cleaning up the ambiguities and finishing definitions in the core protocol.
More information about the Standards