[Standards] Proposed XMPP Extension: Buddycloud Channels

Lance Stout 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
name.


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
protocol).





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.


— Lance

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.jabber.org/pipermail/standards/attachments/20140429/e8ffdcd8/attachment.sig>


More information about the Standards mailing list