[Standards-JIG] Proposed Changes to JEP-60 - PubSub
jabber.org at ralphm.ik.nu
Mon Jun 7 20:27:28 UTC 2004
On Mon, Jun 07, 2004 at 02:24:20PM -0400, Fletcher, Boyd C. J9C534 wrote:
> > -----Original Message-----
> > From: standards-jig-bounces at jabber.org
> > [mailto:standards-jig-bounces at jabber.org] On Behalf Of Bob Wyman
> > Sent: Monday, June 07, 2004 1:01 AM
> > To: 'Jabber protocol discussion list'
> > Subject: RE: [Standards-JIG] Proposed Changes to JEP-60 - PubSub
> > Fletcher Boyd wrote:
> > >use of only AlphaNumeric characters simplifies parsing
> > You have been writing messages that make it sound like
> > you're saying that JEP-0060 is horribly broken. To suggest
> > that one of your top "must be fixed" problems is simply
> > something that "simplifies parsing" doesn't make it sound
> > like the problems are as bad as you have been suggesting...
> its worst. as indicated by your need to develop your own pubsub implementation
> > >> NodeIDs MUST have semantic value in implementations of pubsub.
> > > there is no requirement that the client implement hiearchical nodes.
> > > its just that the core server must support them. you don't
> > have to use
> > them.
> > I build a server that provides content-based pubsub
> > services over JEP-0060 and has no use for hierarchical
> > nodeIDs. You are suggesting that my server be *required* to
> > provide support for features that only have meaning in
> > old-style topic-based systems even though they will never be
> > used by my server?
> yes. all pub sub servers should be compliant with the specification. but you shouldn't have to write a pubsub server. a generic one should be sufficient if the specification was sufficient robust and well-defined.
My opinion is that this JEP should form the basis for creating
publish-subscribe applications over Jabber/XMPP. In no way was this document
targetted for one specific kind of use, as many have commented on earlier.
Of course, if you implement a pubsub service, it should be compliant with
this JEP. However, this doesn't mean that has to be a complete implementation.
Again, I can think of, and many have in the past come up with, many different
uses of pubsub (in the Jabber universe), and I think we would do the community
a big disservice by only catering part of potential users. Let me expand.
Consider an network of embedded systems, for example in a car. There are
several semi-independend subsystems in such a car that can benefit from
a publish subscribe distribution system. For example, the dashboard shows
speed of the vehicle. But, as the car slows down when coming from the highway,
the volume of the car stereo is automatically tuned down, to sustain the
same perceptive level. The dashboard can subscribe to a node to which
the current speed is occasionally published. So can the stereo.
Although hierarchies could be useful in this setting, I wouldn't use them,
and it would be pretty strange to have to implement that into the pubsub
service in your car. Why? It has different requirements to the amount
of data transferred and there are constraints to the environment in which
it has to run in.
I'd rather use protocol to discover whether the service I'm talking to
has implemented. Throwing a disco#info at the pubsub service's JID
could do the trick. We only have to agree on a set of feature vars that
specify such optional features as hierarchies. If you only want to implement
the very bones stuff, you can, and just don't implement disco whatsoever.
This is acceptable, because if you are talking to a service that doesn't
even do disco, it's not a generic service anyway.
> from a previous email:
> 1) No clear, concise, non-ambiguous way to do updates to items and nodes
> 2) Explanation for notification does not explain how:
> a) Does a change in a child node cause a notification to be sent if the user is subscribed to only the parent node.
> b) Does a change in a parent node cause a notification to be sent if the user is subscribed to only the child node. Is subscribing to a child node and not the parent even possible?
> c) What are te available options for configuring notification?
> d) Are notifications sent out when a child node is created or deleted?
> e) Does subscription of a parent node imply subscription to child node?
Node hierarchies and the notification behaviour can be specified in a
seperate JEP that builds on JEP-0060, and registers a special feature
var for discoing.
> 3) node hierarchy support is indeterminate. How do I know if the server supports node hieracharies?
> 4) in item 8.1.9 "Implementations of pubsub that choose to persist items MAY allow entities to request existing items from a node." -- MAY allow??? how does a client determine that without actually trying to get an item from node. Its things like this that are problematic.
This is something that can be stored in the nodes configuration. Examples
are in the JEP. If the node is not persistent, you can't ask for past
items. If it is persistent, it should logically also allow you to request
existing items. If you mean that, I agree.
> 5) in item 8.1.8 "Implementations SHOULD use the Data Forms protocol to accomplish this configuration." Well if I don't use Data Forms then how to you configure options...
You can also send custom namespaced elements instead. This was requested at
design time, and doesn't look like a problem to me. If you don't recognise
the custom stuff, you ignore it, like with all Jabber protocols.
More information about the Standards