[Standards-JIG] Proposed Changes to JEP-60 - PubSub

Ralph Meijer jabber.org at ralphm.ik.nu
Fri Jun 4 08:12:05 UTC 2004

On Thu, Jun 03, 2004 at 10:22:19PM -0400, Fletcher, Boyd C. J9C534 wrote:
> we are still dancing around the fundamental issue, that the specification is not sufficiently defined. we need to clarify the specification in at least these areas:

You've stated this multiple times, but clearly, as I observe the nature of
all replies, you still haven't made clear *why* we /need/ to clarify the
specification. You only name what you want to see changed, but not how
you came to that conclusion. I can't see you string of thoughts.

Let's go back to what you are working on. You said in one of your later
messages that you are implementing a whiteboarding application using pubsub.
First of all: cool! But then.

> 1) hierarchy separator

You say you think nodes ids should always be hierarchical. Why is that? In
your application, how do you start using pubsub? Who creates the node, and
why is it important to have it in a hierarchy? For Mimir, the nodes I
create /look like/ they are in a hierachy, but a the moment, that isn't
really important. For the avatar case, people disco a person's own JID
to discover the node id (and server) of its avatar pubsub node. The
avatar owner's client itself can just ask for an instant node, as it doesn't
really care about the name, just that a node exists and that he nows the
name so that he can register it with the disco component.

But if you do need hierachy in your nodes, how does the client know how to
get to the node. If you want to let the client try the root of the hierarchy
and drill down until he finds what he is looking for, you can just use
what is described in section 8.1.10. You actually don't need to know the
hierarchy separator character, because you just get the names of the
children in the next disco.

If you need another way to determine the actual name of a node, for example
related to the owner's jid, you can't use a generic pubsub service anymore,
because now the node id has semantics. If you were to store avatars like
for example 'avatars/ralphm at ik.nu', etc, you have to make sure that only
ralphm at ik.nu can create that node. Also, when the owner's jid doesn't match
the jid part of the node id anymore (transfer of control), you have a problem.

> 2) how notification works

IMO, how notification works for a particular node, should be stored in the
node's configuration. We can standardize on the names used for that as
was suggested earlier. Adding new attributes new attributes to <create/> is
a useless extension, since the JEP already allows to jointly create and
configure a new node. This is stated between examples 5 and 6 in section 8.1.1.

> 3) changing numerous SHOULDs to MUSTs

The reason that there is a SHOULD instead of a MUST there (and other places),
is because I can think of many applications where you really don't need node
and subscription configuration, and just want a simple, barebones
implementation of a pubsub service, possibly part of a bigger system, where
configuration like this is either hardcoded or configured out-of-band. Areas
where this applies includes machine-to-machine communication between embedded
systems. People asked for this way back when we defined the specification,
as you can read in the archives. Actually, subscription configuration wasn't
even there in the beginning.

> 4) revamping of the itemID and nodeID naming

I think the above at 1), applies here as well.

> 5) specifying itemID & nodeID update behavior

I think the above at 2), applies here as well.

> JEP-68 and Disco don't apply to the above. I'm not suggesting adding new features that can be discovered or that even those above should be capable of being discovered. I consider them core functions. What should be discovered is something like whether the server supports persistence.

Sometimes, I don't need evolution to read my e-mail, and mail(1) is sufficient
an implementation. Don't assume everybody needs a full-fletched pubsub service
when this is probably mostly not true. XMPP/Jabber is not only for IM related
stuff. People in this community also use it for business applications
(financial transactions, for example), and don't actually need all the fancy

Again, if you still don't agree, come up with real, concrete examples of
implementations (in stead of just your conclusions). You can use your
whiteboarding app as a starting point. Walk us through what you wanted to
achieve and why it didn't work like you desire. If you're concerned about
IPR issues, think up an analog problem with the same properties and issues.



More information about the Standards mailing list