[Standards] Pubsub to atom mapping :)
Sergey Dobrov
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. :)
--
With best regards,
Sergey Dobrov,
XMPP Developer and JRuDevels.org founder.
Sergey Dobrov
add the ability to view item's revisions than make some kind of item
grouping.
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?
Any opinions?
Peter Saint-Andre
> 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.
--
Peter Saint-Andre
https://stpeter.im/
Sergey Dobrov
> 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?
Peter Saint-Andre
> 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
Sergey Dobrov
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?
--