[standards-jig] Pub/Sub Explanation
theo at theoretic.com
Tue Apr 16 18:18:22 UTC 2002
DJ Adams wrote:
> On Mon, Apr 15, 2002 at 10:20:52PM -0600, Dave Smith wrote:
>>I take personal responsibility for not being more forthcoming with details.
>>I could blame it on any number of circumstances, but the fact of the matter
>>is that I haven't taken the time and focus to layout the details of what I
NP. I personally didn't let it bother me any because I knew any problems
with JINC would be worked out for the better no matter what, and all the
developers at JINC were good people who had the protocol's needs at heart.
> This is an important point. We do need to see if we can bring together the
> efforts amongst JEP 21, 24 and this new one, but at the same time, it would
> be counterproductive in the long run to force them together despite any
> fundamental differences. The Jabber world lives with different protocols
> already - for example, the conferencing protocol (groupchat, conference,
> and JINC's own). Diversity is sometimes as important as conformity.
Well, browsing through the public JEPS, I can see them coming together.
Of course, that is without seeing anything from JINC yet. Anyways, I
think they should all come together if even remotely possible. It will
make for a better experience for the many beginning programmers starting
to use Jabber.
> Well, (we've discussed this already, but offline), both Piers and I
> don't see the need for such a distinction. A pub/sub system needs a way
> of identifying the 'subject' (or topic) of subscription or publication.
> The means of identification needs to be as flexible as possible, to allow
> publisher and subscriber to independently come to a 'contract' where what
> is to be published and subscribed to is described in that subject. Use of
> a namespace (remember, a namespace can be *anything*, not just a colon-
> separated list of keywords, or a URL) to specify the subject gives ultimate
First: a namespace can't be *anything*, can it? no spaces, etc.. it's
restricted to the URN rules. Second: I am not understanding the
distinction between a topic and a category. I assume topic is the
subject of the published material, but what good would a category be for?
> Secondly, (again, as discussed offline), there are implications (shown
> below in your use cases, and in the example XML you've shown us) of 'topic
> management' by the pubsub component, that are linked to these two
> things 'topic' and 'category'. Pub/sub should be pub/sub, and topic
> management should be done outside of the protocol (for example, having
> the (potential) subscriber browse the publisher would enable the publisher
> to autonomously manage his own subjects and arrange them into whatever
> hierarchy (or otherwise) he desired. In my opinion, topic management
> does not belong in a pub/sub component. Indeed, to require administration
> at the pubsub component to manage topic creation and those mechanisms
> that you're proposing (again, discussed offline in part), does not bode
> well for smooth operation.
Yes, exactly. I had the same thought. PubSub should only be PubSub. All
management and info/query functions should be outside the scope of it.
Using a "jabber:iq:pubsub-management" namespace or somesuch.
/\ Adam Theo, Age 22, Tallahassee FL USA
//\\ Email & Jabber: theo at theoretic.com
// \\ (Boycotting AOL, therefore no AIM or ICQ)
=//====\\= Theoretic Solutions: http://www.theoretic.com
// || \\ "Bringing Ideas Together"
|| Jabber Protocol: http://www.jabber.org
|| "The Coolest IM on the Planet"
|| "A Free-Market Socialist Patriotic American
|| Buddhist Political Philosopher."
More information about the Standards