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 > grouping.
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: >> Hello, >> >> 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. :) >> > > -- Peter Saint-Andre https://stpeter.im/
