[standards-jig] PubSub JEP high-level summarization

Peter Saint-Andre stpeter at jabber.org
Thu Nov 7 23:47:19 UTC 2002


Hi Casey, thanks for getting this discussion started. We'll definitely be
talking about this in tonight's Jabber Council meeting:

http://www.jabber.org/council/meetings/agenda-2002-11-08.php

I'll try to write up minutes after this one -- last week I was just too
busy.

Peter

--
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.php

On Wed, 6 Nov 2002, Casey Crabb wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> In an effort to get the discussion on PubSub moving forward again I have
> written a short, very high-level summary of each of the JEPs on PubSub,
> along with a list of high-level issues I think need to be resolved in
> the PubSub world.
> 
> 0021 -
> ~  Solving:
> ~           event distribution.
> 
> ~  * Has payloads optionally
> 
> ~  * Has 'guaranteed delivery' optionally (by forcing an iq
> ~    type=result)
> 
> ~  * Published data is 'form-less' as in recipient must know particular
> ~    structure of particular namespace ahead of time
> 
> ~  * topic scoped by sender jid.
> 
> ~  * seems like a single jid can publish a single type of info (or
> ~    subscribers will be subscribed to all events from publisher's jid)
> 
> ~  * authorization to subscribe to event is passed through to publisher
> 
> 
> 0024 -
> ~  Solving:
> ~           * information distribution to only interested individuals
> 
> ~           * information distribution OUTSIDE of session
> ~             management. (component to component)
> 
> ~  * Has payloads, not references
> 
> ~  * topic scopes to xml namespaces
> 
> ~  * Can subscribe to generic namespaces that anyone might provide
> 
> ~  * Published data is 'form-less' as in recipient must know particular
> ~    structure of particular namespace ahead of time
> 
> ~  * Publisher can't see who is subscribed to its data
> 
> ~  * Concept of PubSub component proxy for intra-pubsub component
> ~    communication
> 
> 
> 
> 0028 -
> ~  Taken offline, can't look at it anymore.
> 
> 
> 
> 0036 -
> ~  Solving:
> ~           the subscribe and subject creation portion of pubsub ONLY
> 
> 
> ~  * No payloads, only references (according to introduction wording)
> 
> ~  * topic scopes to arbitrary strings with no required semantic
> ~    context -- they seem to be assigned when subject is created.
> 
> 
> 0040 -
> ~  Solving:
> ~           robust information distribution in a pubsub system
> 
> ~  * PubSub components can subscribe to each other and redistribute
> ~    information
> 
> ~  * Seems to sit on top of pre-existing pub/sub system (possible
> ~    intended 0024).
> 
> ~  * Payloads optional.
> 
> ~  * Concentrates heavily on ensuring data either gets through, or can
> ~    be detected and recovered by the recipient in the case it doesn't
> ~    get through.
> 
> ~  * Published data is 'form-less' as in recipient must know particular
> ~    structure of particular namespace ahead of time
> 
> 
> - ---------
> 
> Here are the issues I see
> 
> 1] How do we scope PubSub topic id's?
> (My vote is reserved 'space' for JANA to assign, outside of space is
> freeform)
> 
> 2] Payloads/No Payloads/Optional
> (My vote is Optional)
> 
> 3] Creation of new topics
> (My vote is JANA, and freeform outside of reserved space)
> 
> 4] Permissions for subscribing to topics
> (My vote is 'you're publishing it, why do we need permissions?')
> 
> 5] S2S Bandwidth crazy? Should each server have a pubsub component that
> will proxy for other's server for local users?
> (Not sure what the impact will be compared to messages, but I think
> proxy pubsub is a good idea, instead of transmitting, N times over the
> wire to a single server transmit once to server and a list of people its
> going to)
> 
> 6] Administration of subscription lists, can publisher see who is
> subscribed, can they remove people, can they add people?
> (My vote is publisher can see, but not touch)
> 
> 7] Guaranteed delivery/offline delivery.
> (We need guaranteed delivery as an option)
> 
> 8] Subscription Lifetime
> (I vote it stays until removed, through hell-or-highwater sort of thing)
> 
> 
> 
> What other issues have I missed?
> Lets move pubsub forward.
> 
> - --
> Casey
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.0 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQE9yX7OUidG/HUEju8RApuGAJ9MjNiqFf57HrmRFPmlFCLqjuXlFwCeOWp+
> ZLowRKpghDKBrobdsNhLa8U=
> =cNWO
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
> 




More information about the Standards mailing list