On Mon Apr 26 17:06:53 2010, Florian Zeitz wrote:
On 26.04.2010 11:57, Kevin Smith wrote:
> I'd not noticed the oddness in the get-user-roster command in
Service
> Administration before. It seems out of place with the rest of the
XEP
> (which claims to be an ad-hoc profile) to have this command in
there
> that requires special client support. Should this be returned in a
> text-multi instead (or as well)? I can see the appeal of re-using
> roster semantics for returning the roster, but it doesn't seem to
fit
> with the idea of a generic admin interface.
>
> Thoughts?
>
> /K
I had this "problem" some time ago when implementing this for
Prosody.
(Don't ask me why I didn't bring it up here, probably just forgot)
I choose to additionally return the roster XML in a text-multi
field.
This is admittedly pretty ugly, but as close as I got when trying to
convey the same information.
I'd say strip it out of XEP-0133, and add in the ability for entities
other than the user to modify the user's roster, and define semantics
for when they do.
For example, it might be interesting to have roster edits either
override the existing subscription, or else cause suitable <presence
type='[un]subscribe[d]'/> stanzas to be emitted.
Then we-XSF have a standardized roster management and manipulation
protocol, and we-Isode are certainly interested in having one.
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
