generic storage (was: Re: [Standards-JIG] Publish-subscribe use cases)
stpeter at jabber.org
Thu Nov 3 22:09:22 UTC 2005
This description was very helpful -- thanks for posting it. I agree with
your points about subscribing from explicit resources (though I'm not
quite so sure about presence-based generation of notifications, since
that could be difficult in some server implementations -- I don't know
as much about that). I have a comment first about generic storage...
Ralph Meijer wrote:
> Generic Storage
> Some have expressed the desire to have a generic storage facility,
> possibly with access controls. Since pubsub does already have ways to
> handle publishing and change notifications, it seems to nicely coincide.
> The recent remarks on allowing item-gets for non-subscribed entities
> should help here.
> This also shares a few of the same goals as SPPS, in that it would be a
> virtual service for every entity's JID. But other requirements, like
> access control and item history are do not. So maybe we could have SPPS
> and some other storage focused profile for which the actual node
> namespaces coincide. Some nodes being handled like SPPS, some for
> storage. In any case, these use cases should probably not be confused
> with eachother.
It's not clear to me that item history is necessary for generic storage.
For example, we don't have history for vCards or jabber:iq:private and
no one has ever complained about that.
The access control for generic storage could be the same as the access
control for SPPS, via the different pubsub node types we've been
discussing. So it seems to me that:
1. A node of type "public" could be used for storage, retrieval, and
publishing of world-readable information -- just like vcard-temp today
or the public information storage that's implicit in JEP-0049.
2. A node of type "presence" could be used to share less-public
information (perhaps geolocation or whatever) with anyone who is
authorized to see my presence -- giving us integration with the access
model of presence authorization, which is one of the strengths of Jabber
in the first place.
3. A node of type "rostergroup" could be used to allow access only to
contacts in a specified roster group or groups -- giving us integration
with the mental grouping and implicit trust model of rosters (I trust
the few people in my JabCore group more than I trust the many people in
my JabUsers group).
4. A node of type "resricted" or "approve" would require approval of
each subscription request (not part of SPPS).
5. A node type of "private" could be used to store information that is
for use only by me (think JEP-0049). I publish to it and can retrieve
the last item, then publish an update if I want (just like iq:private).
Plus I could subscribe different resources so that my "Home" resource
gets informed when my "Work" resource updates my bookmarks or whatever.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards