[Standards] XEP-0313: why it is *really* not a good idea to use MAM with Pubsub
kevin.smith at isode.com
Sun Jan 24 17:25:44 UTC 2016
On 6 Jan 2016, at 11:08, Goffi <goffi at goffi.org> wrote:
> - 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.
Aren’t you going to have huge troubles with stanza sizes in that case? It seems like once you start wrapping multiple pubsub items together you’re going to start exceeding stanza sizes and needing to deal with the code for merging them anyway.
> - 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.
I think that’s a fairly simple extension for someone to spec, isn’t it?
> - 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
> 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?
I imagine you request the form for the node you’re interested in querying. If that’s not clear, we should make it so.
> - 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.
This doesn’t seem insurmountable. We have data forms for the queries if we want to change behaviour.
> - 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.
I would be very keen to move towards one method for doing history queries and not having the current plethora (offline messages, MUC context, PubSub, …).
> 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
I think the effort would be much better spent adding MAM extensions as necessary.
More information about the Standards