[Standards] microblogging maintainer :)
dave at cridland.net
Mon Dec 20 14:45:37 UTC 2010
On Mon Dec 20 16:20:23 2010, Thomas Baquet wrote:
>> The trouble with this model is that you're redefining how pubsub
>> works quite radically.
>> Nodes, currently can be one of two types:
> I missed that...
>> As such, I'd expect implementations of this to support many items
>> per node, and full access model control to allow (or disallow)
>> replies on the node as needs be. There's really no need to a
>> protocol extension to pubsub to support this.
> Perhaps is this the simplest way - delegate the work to the client
> implementation: if the user has a write access on a node, the
> client has to propose to answer to the item. In this case, there is
> a leaf node for each published item.
No, there's a single leaf node for *all* the published items. And I'd
argue that if you can't post to a node, then direct replies are not
supported by that node.
> No need of XEP for this, as you told. - On this, Floriant was right.
No, there's still a need to document how it should work, but there's
no need to extend the protocol.
> Then, the problem still the "pointer" - user can choose to post the
> reply on his own pubsub, in this case, he must send an pointer item
> on the original item's. So, how do we define the pointer? I began a
> little proposition about this (point 5 of the draft), but still
> incomplete - and, why not, add an attribute to define if is it a
> reply or a "trackball" (like in wordpress), a copy of the original
> etc. ?
You can place the pointer within the payload. I'd be quite surprised
if there weren't one available already within Atom. There's certainly
replies, etc, with the threading extension, I'd imagine there's a
canonical URI some place there.
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards