Managing Profiles
In a continuing effort, 
stpeter makes some
observations about managing
profile data in Jabber. More specifically, how to do that
using our publish-subscribe
extention. Here are my thoughts.
What if you posted your profile information to just one node, having the fields distributed among various node items? Subscribers could select the desired fields by using subscription configuration, resulting in a content-based subscription. A subscriber would then only get notifications for those fields, and in the beginning fetch the complete view of the profile by just retrieving all node items (for his subscription).
What about access control? Well, you could base the access control
on the supplied selection of fields. The authorization form for the
subscription could include this information as a custom field (starting
with x- as specified in Field Standardization
for Data Forms or by registering it with the Jabber
Registrar). After initial configuration, a subscriber may not change
this configuration option (it would not show up when trying to
reconfigure the subscription later on). Not sending a configuration
form along with the initial subscription request would imply wanting
access to all fields. This is partly because so-called
unconfigured
subscriptions have already passed the
authorization phase.
To comment on general vs. application specific pubsub services, I suppose that many applications would need some customization in the service implementation. I think this is at least true for any content-based pubsub service (because you need to have a way to query the content). On the other hand, for simpler applications like extended presence, generic services should be sufficient.
Another possibility is pubsub applications that use only parts of the protocol. For example, one could have a service that does allow subscribing to nodes and receiving notifications, but denies the creation of new nodes or publishing via the pubsub protocol. Instead, a notification could be the result of some out-of-band event: a change in internal state or data received via another protocol (XMLRPC, e-mail, etc.). Or, my idea of how Mimír should be re-implemented as a customized pubsub service that allows plain-text notifications based on presence, and has side effects in the form of a personal news page.