On Wednesday, July 13, 2011 08:40:06 AM Stephan Maka wrote: > 1) The specification imposes a naming scheme on Publish-Subscribe nodes. > Until now, XEP-0060 users could have assumed them to be rather > free-form.
The proposed spec uses special naming for two reasons: 1) To make it easy to locate the set of nodes associated with the same conversation. To work around this we could say that a conversation must specify not simply a node prefix, but must specify the full name of all three nodes. 2) Parameters are passed by suffixing them to the node name. To work around this we could pass them in some separate <options> section possibly. Given that we already precedent for fixed nodes names in PEP, I figured the node naming rules weren't anything to be terribly concerned with. > There is a general question on how a particlar content model is > designed. First, there is the "Twitter" model: posts are aggregated in > per-user nodes and reference posts in other nodes. > > On the other hand, services such as Facebook, Google+ and buddycloud > aggregate comments in the same context of the referred post. That could > mean, the whole conversation goes into a single Publish-Subscribe node. > This is what we at buddycloud do. A separate node for comments is > specified by the new Commenting XEP. I don't quite follow this. By "same context" do you mean to put comment items into the same node as a status messaging being replied to? > 2) Discussion flow modelling has been approached by The Open Web[tm] as > well: ATOM Threading Extensions[1] and the Salmon protocol[2]. > > ATOM Threading Extensions indicate what parent item a comment is > referring to. They can be applied to Publish-Subscribe content nicely, > if we had a URI scheme for referencing individual items, such as: > > <thr:in-reply-to > xmlns:thr="http://purl.org/syndication/thread/1.0"; > ref="0f72afbe-a9d4-11e0-b0bc-0024bed71c0a" > type="application/atom+xml" > > href="xmpp:comments.example.com?pubsub;node=coffeetalk/comments;item=0f72a > fbe-a9d4-11e0-b0bc-0024bed71c0a" /> > > Such referencing is entirely missing from the proposed specification. Ah indeed, forgot this. Replies would work exactly this way. > The Salmon protocol, proposed by Google and used in OStatus, allows any > resource to receive comments by indicating an endpoint URL without > mandatory naming schemes. For ATOM content, this is as simple as > <link rel="salmon" href="..."/>. Again, the spec does not force where the conversation must be. Just like how Atom can refer to a salmon URI, it could just as well refer to a JID+node_prefix. > They do not call it only "comments" because, what can be seen from the > variety of ActivityStreams verbs, there are more than just comments on > social networking services: likes, reposts, rsvps, follows, invites, > tags et cetera. This is just nomenclature; /commenting/ names the > category well enough. Indeed. Justin
