[Standards-JIG] Proposed Changes to JEP-60 - PubSub
Fletcher, Boyd C. J9C534
Boyd.Fletcher at je.jfcom.mil
Wed Jun 2 02:40:56 UTC 2004
> -----Original Message-----
> From: standards-jig-bounces at jabber.org
> [mailto:standards-jig-bounces at jabber.org] On Behalf Of Ralph Meijer
> Sent: Friday, May 28, 2004 5:19 AM
> To: Jabber protocol discussion list
> Subject: Re: [Standards-JIG] Proposed Changes to JEP-60 - PubSub
> On Fri, May 28, 2004 at 10:44:15AM +0200, Tomasz Sterna wrote:
> > Fletcher, Boyd C. J9C534 wrote:
> > > [...]
> > >
> > 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.
> > 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
> > of the base protocol they use - they would need to do
> things in it's
> > own ways - and we do not want that (why three JEPs was
> merged to one).
> > In other words - you do not implement pub-sub in client
> direclty. You
> > implement those higher JEPs that are based on pub-sub framework.
> > (This is how I undestand the rationale behind this JEP)
> Yes, this is what we had in mind when this JEP was created.
> Publish-Subscribe is a *Design Pattern*, also known as the
> Observer pattern . The JEP defines how this design pattern
> can be used in Jabber. There are several variants of the pattern.
design patterns are nice and useful in designing protocols. PubSub is a protocol and its not sufficiently detailed enough to be useful for complex applications. I estimate current spec is about 80% complete.
> For example, you want all data pushed in the notification
> itself, /or/ you just want to be alerted that the node's
> state changed, and you can retrieve data associated with the
> notification at a later time. Surely we could have choosen
> just one approach, but that would have limited the use of the
> JEP for certain application areas.
nope, implement both and let the client application decide which it wants to use.
> The same rationale has been used throughout the development
> of this JEP. As Tomasz says, saying you implement pubsub
> (client side), is a useless statement.
> You implement a particular application of pubsub. For
> example, I have created MimÃfr, a Jabber enabled news system
> that uses JEP-0060 for gathering news from various sources.
> So, my news system implements the news transport, /using/ JEP-0060.
> I also implemented JEP-0107 (User Mood) in another
> application. This also uses JEP-0060, but in another way.
> Yes, the applications are incompatible, since you can't
> publish a mood to the news side, or the other way around. But
> the implementation of the managing publish subscribe
> serverside component is the same: Idavoll . I am working
> on Idavoll to become a complete implementation of the server
a complete implementation is impossible with the current version of the specification. It has too many MAY, SHOULD, or POSSIBLIES in it. It is also quite ambiguous in a number of places. Complete implementations cannot be based on ambiguous specifications.
> side stuff needed for writing publish subscribe applications.
> But it will be a generic one. Certain application need more
> configuration options, e.g. filtered notification (based on
> the subscribers presence, location or mood). So you could
> then use a generic pubsub component and extend it.
you mention in one sentence about using a generic PubSub implementation but at the beginning of the email you imply that everyone would have to implement a custom pubsub implementation. All I'm saying is a that a generic pubsub is the ideal solution but that the current specification has too many problems and needs to cleaned up.
> On the other hand, it might be that the node handling is just
> one of parts of a greater, server side system. Then you can
> just implement it from scratch, with the behaviour you
> desire, while still using (again) the same protocol as
> defined in JEP-0060. This has been done for Location Linked
> Information , a project by Matt Mankins (where are you
> anyway, Matt?).
> Can you give *concrete* examples, preferrably with protocol
> exchanges, for cases you think different implementations of
> pubsub applications are incompatible /because of/ JEP-0060?
>  http://c2.com/cgi/wiki?ObserverPattern
>  http://idavoll.jabberstudio.org/
>  http://xenia.media.mit.edu/~mankins/lli/
hummm... let's see
------------ Example 1 ---------------
We need to either implement levels of compliance OR change most of the critical optional sections to mandatory. Things like node and item naming, hierarchical or not, adding/updating/deleting nodes & items, etc. need to be specified. these are things that can be optional. However, what can be done is use language to specifically state what the options are. For example 11.3
" 11.3 Node and item id uniqueness
NodeIDs MUST be treated as unique identifiers. Implementations may treat publish requests with the same NodeID differently. Possibilities include:
* The first publish succeeds, and others with the same ID fail.
* All publishes succeed, each one overwriting the older item.
* Each item is accumulated in some kind of list. ItemIDs are used to indicate and request specific items. The service would assign ItemIDs to enforce uniqueness of ItemIDs.
These options MAY be configurable per node if desired in the pubsub service.
If item identifiers are used, they MUST be treated as unique within the scope of the node. NodeID + ItemID MUST be unique within a given service, and MUST specify a single published item to a single node. Multiple publishes to the same ItemID MAY result in behavior similar to that stated above for nodes (except that multiple items in a list MUST NOT have the same ItemID, since ItemIDs MUST be unique within the scope of a node)."
you could revise it to say (slightly changed from my previous email)
11.3 Node and item id uniqueness
NodeIDs and ItemIDs MUST be treated as unique identifiers. NodeIDs and ItemIDs can only contain AlphaNumeric characters. Implementations must have three methods to resolve NodeID and ItemID conflicts that are selectable by the client when creating the first node as part of the create request. These are:
* OVERWRITE_ALLOWED=False - The first publish succeeds, and others with the same ID fail. This is default behavior if OVERWRITE_ALLOWED is not specified.
original node: <create node="generic/pgm-mp3-player" OVERWRITE_ALLOWED="false" APPEND="false" />
* OVERWRITE_ALLOWED=True - All publishes succeed, each one overwriting the older item.
original node: <create node="generic/pgm-mp3-player" OVERWRITE_ALLOWED="true" APPEND="false" />
* APPEND - A new node/item is created with monotonically increasing number appended to the nodeID/itemID but separated by an underscore. APPEND is false by default.
<create node="generic/pgm-mp3-player" OVERWRITE_ALLOWED="false" APPEND="false" />
<create node="generic/pgm-mp3-player_1" OVERWRITE_ALLOWED="false" APPEND="false" />
Item identifiers MUST be treated as unique within the scope of the node. NodeID + ItemID MUST be unique within a given service, and MUST specify a single published item to a single node.
------------ Example 2 ---------------
In "Example 64 - A Client drills down to a second level node" it clearly references the ability for a node to have sub-nodes, however the specification doesn't describe how to create and manipulate sub-nodes.
It also doesn't say if there is a limit on the depth or width of sub-nodes.
Most people have probably assumed that node and sub-node handling are the same however, this should be clarified. In the next example, we show how the naming of sub-nodes is problematic.
------------ Example 3 --------------
Currently "11.5 Handling node hierarchies" says:
NodeIDs MAY have semantic value in implementations of pubsub. If an implementation wishes node IDs to have hierarchical meaning (as is shown in the examples), that implementation MAY choose any naming scheme which is suitable to the hierarchy in question. Identifiers could use slashes, periods, or other special characters as the hierarchy separator.
this is clearly too vague and its impossible to tell what hierachical relationship is. 11.5 could be revised to say:
NodeIDs MUST have semantic value in implementations of pubsub. A PubSub service is required to support hierarchical nodes. Parent NodeIDs are separated from their children by the "/" character. There is no limit on the number of children a node may have or on the number of levels of children.
or alternately, we could be a bit more flexible in the separator specification:
NodeIDs MUST have semantic value in implementations of pubsub. A PubSub service is required to support hierarchical nodes. Parent NodeIDs are separated from their children by the SEPARATOR attribute to the create node command. There is no limit on the number of children a node may have or on the number of levels of children.
<create node="email/boyd" OVERWRITE_ALLOWED="false" APPEND="false" SEPARATOR="/" >
so a couple of email messages could be:
<create node="email/boyd/232.eml" OVERWRITE_ALLOWED="false" APPEND="false" SEPARATOR="/" >
<create node="email/boyd/1958.eml" OVERWRITE_ALLOWED="false" APPEND="false" SEPARATOR="/" >
OR using periods:
<create node="phonebook.757" OVERWRITE_ALLOWED="false" APPEND="false" SEPARATOR="." >
so two sub nodes representing a phone number would be:
<create node="phonebook.757.555.1234" OVERWRITE_ALLOWED="false" APPEND="false" SEPARATOR="." >
------------ Example 4 --------------
How does event notification proprogation work with sub-nodes?
- Do event notifications cascade up and down?
- Does subscribing to one level of a node give notification on all nodes in the tree?
The specifcation talks very little about notification, yet notification is a key part of the Observer Design pattern for PubSub system.
and these are just a few examples. Most of the these are requirements for the PubSub service are not necessarily required for implementation in a client (like for user moods or avatars). It's the feature completeness of the pubsub service that is critical.
More information about the Standards