[Standards] XEP-0313: why it is *really* not a good idea to use MAM with Pubsub

Goffi goffi at goffi.org
Wed Jan 6 11:08:16 UTC 2016


G'day,

MAM is a great tool which solves several problems for messages management. It 
also offers the ability to get items from a PubSub node when the "node" 
attribute is used.

We have implemented this feature in our PubSub/PEP component, and I haven't 
seen any other implementation for PubSub so far (if you know any, please tell 
me).

But I have to say that MAM is really badly adapted to PubSub, here are the 
major reasons:

- All items a returned in separate <message> stanza, wrapped in a <forwarded> 
element, one item per stanza. This both is a waste of bandwidth and make the 
task more difficult for the client as it must track each <message> and the <iq> 
result to known when a page has been received. A simple <iq> query like for a 
PubSub items retrieval would be much more better.

- Requests are made on one node. But it is desirable to be able to do requests 
on several nodes, or on nodes which match a pattern. For instance, in XEP-0277 
comments node are in the form 
"urn:xmpp:microblog:0:comments/dd88c9bc58886fce0049ed050df0c5f2" and it would 
be usefull to request all items from a node starting with 
"urn:xmpp:microblog:0:comments". With MAM I can't request all comments 
published by Romeo.

- this one could be easily fixed, but currently we can't do filtering on PEP 
without requesting a particular jid. With microblog, we want to be able to 
request e.g. all items with the category/tag "XMPP" regardless of the author.

- There is no way when a service offer MAM both for message and PubSub (e.g.: a 
MUC component with PubSub abilities (MUC 2 ?), or the server itself when it 
offers PEP) to know if the filtering fields apply to messages, or PubSub, or 
both.
Look at section 4.1.5 "Retrieving form fields", how can I know if 
"urn:example:xmpp:free-text-search" can be used for PubSub or not?

- section 4.2 says that "The archive results MUST be sorted in chronological 
order", that totally make sense for message archives, but in the case of 
PubSub this is incoherent with the classic items retrieval ordering (most 
recent item first), and we may want to sort on other fields than publication 
date: for instance item updating date vs publishing date, or size of files 
tracked with pubsub.
Of course we can reverse order easily with RSM, but though it's not natural, 
and we can't sort on other fields.

- overall, PubSub already manages archives by design, but it is lacking a good 
searching tool. Even if it is tempting to use MAM with PubSub because we can 
have filtering "for free", I really think it is not adapted at all, and PubSub 
deserve a real dedicated searching/filtering tool.

If other people are interested, I would like to work on a "PubSub searching" 
protoXEP. PubSub will probably be the core of many major features in XMPP in 
the future, so we need a good, generic, and extendable way to search/filter 
items.

Regards
Goffi



More information about the Standards mailing list