[Standards] microblogging maintainer :)

Thomas Baquet ld.blackfox at gmail.com
Mon Dec 20 13:10:19 UTC 2010

On 20/12/2010 07:18, Florent Le Coz wrote:
> On 12/04/2010 07:55 PM, Thomas Baquet wrote:
>> I've written a first draft (full of awful errors, certainly); what do u
>> think?
> Hello,
> Some comments on this draft (sorry if some of them are pointless. I'm
> still not an XMPP expert):
> - Do you think this should be part of the XEP-0277 or should this be a
> separate XEP?
> - I don’t understand why the publishing entity would decide to create
> the reply-node on an other node than where the item is being published.
> Wouldn't it be simpler to just create the reply-node as a child of the
> node where the item is published?
> This imply, for example, that the microblogging node
> (urn:xmpp:microblog:0) MUST be of type collection, if the service wants
> to permit replies to microblog-posts. Isn't it?
> - I think "allow-reply" and "reply" are a bit redundant.
> 	To allow users to reply to an item, the publishing entity MUST include
> a<reply />  element as a child of the<item />  element it wishes to
> publish.  This<reply />  element MUST be empty and MAY contain a "node"
> attribute indicating the child node the server MUST create and where
> replies to this item SHOULD be published.  If this element doesn’t
> contain any "node" attribute, this reply-node defaults to the item’s id.
> Example 1. User publish an item on a node
> <iq type='set'
>    from='hamlet at denmark.lit/blogbot'
>    to='pubsub.shakespeare.lit'
>    id='publish1'>
>    <pubsub xmlns='http://jabber.org/protocol/pubsub'>
>      <publish node='princely_musings'>
>        <item id='bnd81g37d61f49fgn581'>
>          <entry xmlns='http://www.w3.org/2005/Atom'>
> 	<!-- SNIP -->
>          </entry>
>          <reply node="reply-bnd81g37d61f49fgn581" />
>        </item>
>      </publish>
>    </pubsub>
> </iq>
> Example $$. Server will reply:
> <iq type='result'
>    from='pubsub.shakespeare.lit'
>    to='francisco at denmark.lit/barracks'
>    id='items1'>
>    <pubsub xmlns='http://jabber.org/protocol/pubsub'>
>      <items node='princely_musings'>
>        <item id='bnd81g37d61f49fgn581'>
>          <entry xmlns='http://www.w3.org/2005/Atom'>
> 	<!-- SNIP -->
>          </entry>
> 	<reply node="princely_musings/reply-bnd81g37d61f49fgn581" />
>        </item>
>      </items>
>    </pubsub>
> </iq>
> With the help of this XEP, we could have two microblogging models.
> - The twitter/identi.ca-like model:
> items are published with an Open access model, with no<reply />
> element. User can still “respond” in their own microblog, as defined
> currently in 0277.
> - The Facebook/diaspora-like model:
> items are published with a Roster access model, with a<reply />  element
> as defined above.
> This second microblogging model could be defined in an additional XEP.
> (for a total of 3 XEPs : 0277, Reply On Pubsub, Microblog Second Model)
I'll answer in the same order of your questions:
- I think it must be an nother XEP, cause it can be used as a comment 
system - I mean any kind of form content allowing answer.
- As written in the draft, "The client MAY add a “reply” attribute which 
gives the parent existing collection node. The default value of this 
attribute is the node where the item is published." - Actually I was a 
sick when i've written this draft (perhaps that's why I couldn't express 
me correctly --), but I would meant that by /default/ this is a child 
node of the node where the item is published. But, that can be a nice 
feature if the user is available to choose the node where the item will 
be published;
- I'm agree with you, it's a bit redundant
- I though about this option, but finally, discard it, cause a pubsub 
item must have at most one child; but this is a better idea

Thomas Baquet (aka Lord Blackfox)

Jabber ID: ldblackfox at papaya.im
Website: http://www.lordblackfox.net/
Twitter: http://twitter.com/#!/LordBlackFox

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20101220/19321293/attachment.html>

More information about the Standards mailing list