[Standards] Proposed XMPP Extension: Buddycloud Channels
lancestout at gmail.com
Wed Apr 30 03:05:34 UTC 2014
I've started reviewing Buddycloud Channels, and have some questions/comments:
- Is Buddycloud intended to become a generic term, like PubSub/MUC/Jingle?
I'm curious because it is giving me the same cautious pause as if this
had been submitted by Facebook and named "Facebook Channels", using
the name of a corporation or other trademarked term in the protocol
The disco identity registered here is for pubsub/channels. Would
simply Channels be a better term? (XEP-0060 doesn't use the term
channel, so no conflict there)
- Section 2:
It says that a server can have one Buddycloud channel server. Is this
an artifact of the current Buddycloud implementation, or a restriction
imposed by the protocol?
- Section 6.1.1:
XEP-0060 doesn't currently allow for using multiple <items />
elements like that. It might be better to have those as children of a
<recent-items /> element.
- Section 6.3:
While the Buddycloud service is using Atom for entries, does that need
to be specified as part of this XEP? Some of the tables indicate that
non-Atom content is used already.
- Section 9.1 Inbox is missing?
Although Section 9 seems superfluous right now (that's more a
description of the Buddycloud project/service as a whole, not of this
On the whole, I'm liking this so far. Most of my concerns stem from
balancing documenting Buddycloud as it currently works vs making
things a bit more general to be useable in non-Buddycloud projects.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Standards