generic storage (was: Re: [Standards-JIG] Publish-subscribe use cases)

Peter Saint-Andre stpeter at jabber.org
Thu Nov 3 22:09:22 UTC 2005


Hi Ralph,

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. 
Pretty slick.

Thoughts?

Peter


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20051103/abf38b52/attachment.bin>


More information about the Standards mailing list