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
signature.asc
Description: Message signed with OpenPGP using GPGMail
