[standards-jig] PubSub JEP high-level summarization

Casey Crabb crabbkw at nafai.dyndns.org
Wed Nov 6 20:42:54 UTC 2002


-----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-----




More information about the Standards mailing list