[Standards] Pubsub to atom mapping :)
stpeter at stpeter.im
Mon Feb 27 23:36:53 UTC 2012
On 2/27/12 12:36 AM, Sergey Dobrov wrote:
> I think now that the second option is more suiting: it will be easier to
> add the ability to view item's revisions than make some kind of item
Yes, I think that's good: pubsub itemid = atom:id.
> The other thing here is linking: atom:link needs attributes "ref" and
> "href", but href usually points to the atom feed at all and ref points
> to the specific entry in the feed by it's atom:id. Then, should we point
> to the node there and not to the specific item in the node? Then we can
> exclude atom:id from entries as superfluous. Have we to change Atom's
> xmlns then?
I don't see any harm from duplicating the atom:id in the payload.
> Any opinions?
> On 02/24/2012 08:10 PM, Sergey Dobrov wrote:
>> Pubsub specifications often refers to the Atom format as a payload.
>> Nevertheless, there are some confusing things that makes it hard to
>> understand how to map atom to pubsub in some cases that are outside of
>> the specifications. The reason I want to solve them is in XEP-277 which
>> I need to update to implement some of must have feature into my
>> microblogging platform.
>> Here I suggest to discuss these problems.
>> The hardest problem here is how to map atom:id
>> (http://tools.ietf.org/html/rfc4287#page-19) element to the pubsub item
>> id and closely connected to it problem with the "Update" post feature.
>> The problem is that we have two different entry id fields and it very
>> important to understand which means what to make protocol useful.
>> I see two possible ways here:
>> 1) pubsub item id identifies the concrete revision of an item. Thus, if
>> we have to update the item then we just post a new item to the node with
>> the same atom:id and another pubsub id. Benefit here is that if we link
>> from another place to this item (for example, in the <in-reply-to>) then
>> it will be a link to this concrete revision and will never confuse with
>> other revisions. Another benefit is that we can to track any changes to
>> the entry since all of them are stored in the node. But this option has
>> one strong disadvantage: we have no way to group these entries to make
>> it possible, for example, to retract the entry entirely with all of it's
>> revisions. I have no idea how we can solve the issue yet.
>> 2) pubsub item id = atom:id. Thus, if we have to update the item then we
>> just update the item. :) Possibly, we need to refuse to use atom:id in
>> payload at all since it's confusing to have two identities that means
>> the same thing. How to address the entry then?
>> Thanks for your attentions, I hope that I was clear enough.
>> Have a good weekend, btw. :)
More information about the Standards