[standards-jig] Publish-Subscribe JEP status

Dave Smith dizzyd at jabber.org
Wed Apr 10 13:29:51 UTC 2002


On 4/10/02 2:01 AM, "DJ Adams" <dj.adams at pobox.com> wrote:

> On Tue, Apr 09, 2002 at 10:52:19AM -0600, Dave Smith wrote:
> 
> So I'm not sure I understand what you mean with "...decision not to re-use
> what's out there...the JINC pubsub component operates at the component
> level...", as JEP0024 is designed to allow components to take part in
> pubsub as much as JSM users. This was the whole premise of the specification,
> to keep it simple and straightforward and make presence info an optional
> part. 

Well, if you look at all the examples that JEP 21 and 24 use, they all have
elements which are defined in the jabber:client protocol namespace. This is
really where I have a problem. For instance...

<iq type='set' from='subscriber' to='pubsub' id='s1'>
        <query xmlns='jabber:iq:pubsub'>
          <subscribe [to='publisher']>
              <ns>mynewsfeed</ns>
           </subscribe>
        </query>
      </iq> 

Notice all the IQ stuff there? What I would _prefer_ to see is something
like...

<route to='pubsub.localhost' from='jabber.org'>
   <subscribe xmlns='jabber:pubsub'
                     topic='dizzyd at jabber.org' category='mynewsfeed'>
        <jid>dj at jabber.org</jid>
   </subscribe>
</route>

This packet demonstrates several interesting points. First off, it is
wrapped in <route> packet which is appropriate for direct use on the jabberd
message bus. For the moment, it is possible to send IQ's directly through
jabberd without a <route> element, but when (and if) we ever do proper
namespacing, we'll have to start wrapping packets with namespaces which the
router knows how to route. Another interesting point in the second packet is
the idea that component may be acting as a proxy for another Jabber entity
(the jabber.org JSM in this case is proxing for dj at jabber.org).
dj at jabber.org is the entity that is actually subscribing, but that entity
may not have the ability to directly address the component -- hence the
concept of proxied actions.
  
> If I were to pick a point of discontent, it would be the fact that I'm
> just a little concerned that nothing has been really said until recently.

You mean that no one from JINC said anything until recently?

> (Also, Piers and I discussed topic management, and came to the concensus
> that pubsub should be pubsub, and topic management should be handled
> separately/independently. I think that it's perhaps more of a iq:browse
> 'style' problem space.)

Uh, ok. I think this boils down to a philosophical difference in the
approach -- I view pub/sub as an operation which is done upon a "topic". So
you could give pub/sub a more formal title of "publishing and subscribing to
topics".  I'm not sure how you could handle topic management
independently/seperately. I'm open to discussion tho. :)

> I think we should get together, I can be around for a get-together
> basically anytime between 1600 and 2100 UTC this week. I suspect Piers
> has a similar window...

Ok. I'll see what I can arrange.
 
> I also think that temas would have valuable input at the get-together,
> as it's upon his work which our JEP is based.

Ok.

Diz




More information about the Standards mailing list