I was thinking long about the problem. My problem is that we have to put href and ref into <in-reply-to>. That's ok in Atom: href is for the feed itself and ref to identify the exact item in the feed. But in xmpp we will point href to a pubsub item and there will be the only entry so why to specify ref? Ok, maybe it will be useful for aggregators which will be able to determine where the post was aggregated/duplicated/etc or to restore the post in case of pubsub item retraction.
But, therefore I have another problem: I think that the pubsub node is mapped to the whole atom feed and separate items are mapped to entries. So I think that it will be good to have a singleton item in a node which will represent feed's metainformation, i.e. atom:feed contents without atom:entries elements. The approach with including atom:source in each entry is VERY unuseful from my point of view. I never include them now. For example, it will be impossible to rename the whole blog. I wish to make many updates to the XEP-277 according to mine test implementation which works pretty well except of some bugs in ejabberd's pubsub which have to be fixed in 3.0, I have transports to twitter and juick which seems to work well too. But I don't sure if my decisions are right and suitable for anyone. Could you hint me what have I to do in such situations? On 02/29/2012 02:29 AM, Peter Saint-Andre wrote: > On 2/28/12 1:56 AM, Sergey Dobrov wrote: >> On 02/28/2012 06:36 AM, Peter Saint-Andre wrote: >>> On 2/27/12 12:36 AM, Sergey Dobrov wrote: >>>> 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. >>> >> >> The only one: what if some software will write different values to >> there? Which one will be trusted then? > > Yeah, I thought about that. It might depend on who is relying on which > attribute. E.g., the base XMPP implementation might rely on the pubsub > ItemID for tracking purposes related to the message transport, whereas > the Atom payload might be handed off to a higher-level application that > relies on the atom:id for things like de-duplication. > > Peter > -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
