[standards-jig] Serious Issues with JEP 0024

Adam Theo theo at theoretic.com
Fri Jul 19 04:38:46 UTC 2002

DJ Adams wrote:
> On Wed, Jul 10, 2002 at 11:57:12PM -0400, Julian Missig wrote:
>>I'll have to pipe in here and say I agree with theo. I would definitely
>>like to see a way for pub/sub to work with <message> *and* <iq>. I
> As I mentioned in my earlier reply, I've already been experimenting 
> with this. Also, I forgot to mention, I've also been experimenting 
> with an extra attribute on the <subscribe/> tag - resource. That is,
> to allow the client to subscribe to something and say "but send the
> pushes to me at *this* resource). THe immediate upshot of this is that
> I could use a separate 'subscriber' client to subscribe on behalf of
> my other 'receiver' client(s). 

Excellent to hear! The seperate resource option is a good idea, DJ.

Now, here's an idea on how to allow publishers to publish *any* packet 
(message or iq) to their subscriber base. Packet Headers. I've 
considered Packet Headers as a Core Tool Protocol 
[http://www.theoretic.com/?Jabber_Environments] along with Disco and 
PubSub, and this is how PubSub at least would use Packet Headers. Modify 
the current Packet Headers spec (I'm assuming this functionality 
currently doesn't exist since I have not yet read the spec, will do it 
tomorrow) to also allow to post to pubsub namespaces/topicIDs. As Julian 
points out, it is kinda nasty to put the routing data such as what 
publisher we are subscribing to within the <iq> packet's body instead of 
higher-up with the rest of the routing data. A modified/improved Packet 
Header spec would do the trick, allowing for alot more flexability when 
it comes to addressing and routing.

>>really don't know the details on the server level, but it definitely
>>seems nasty to me to be adding the routing (pub/sub) data within the
>>message, but I don't think we have a better choice right now, do we? I
>>don't know. I know I'd like to see <message> supported, but I also
>>recognize how nasty it is to have routing data hidden down that deep in
>>the message... servers shouldn't have to dig in to route :(
> Ok, just to clear up some potential confusion (probably on my part 
> only), are you thinking of supporting <message/> from end-to-end, or
> just for the leg between pubsub component and subscriber?

I personally was thinking end-to-end. That is, allot the publisher to 
write up a <message> packet, send it off to the pubsub component 
addressed to the particulat namespace/topicID (using Packet Headers), 
and have that <message> more or less echo'ed/broadcasted to the subscribers.

     /\  Adam Theo, Age 23, Tallahassee FL USA
    //\\   Email & Jabber: theo at theoretic.com
   //  \\  (Boycotting AOL, therefore no AIM or ICQ)
//  ||  \\  Theoretic Solutions: http://www.theoretic.com
     ||         "Building Ideas by Bringing them Together"
     ||      Jabber Protocol: http://www.jabber.org
     ||         "The Next Generation Communications Protocol"
     ||  "A Free-Market Socialist Patriotic American Buddhist"

More information about the Standards mailing list