[Standards] Advancing XEP-0280 Carbons
matthieu.rakotojaona at gmail.com
Thu Apr 2 18:52:41 UTC 2015
Excerpts from Kevin Smith's message of 2015-04-02 11:07:57 +0100:
> On 2 Apr 2015, at 10:16, Matthew Wild <mwild1 at gmail.com> wrote:
> >>> - Other types beyond 'chat'.
> >> Seems to be something we want to have. And I would tend to put this
> >> into the carbons XEP too.
> > I'm undecided about this. I think we could get away with just saying
> > that normal+chat should be copied.
> What was agreed at the summit (I’m hoping the minutes for that present
> themselves soon!) was that carbons would be tied in to MAM. So that if
> your server supports MAM, you’d get Carbons for whatever was going to
> be stored in the archive - this could be based on the payloads of the
> message, and might or might not include type=groupchat, depending on
> whether those go into MAM. So it’s not quite as simple (if we still
> want to do what was discussed at the Summit) as just saying ‘type=chat
> and type=normal’.
This is going to be a little off-topic, but not that much.
As I followed the discussion, it appears that we have the situation
where we want all messages to be present (for processing or continuity)
on all resources of a user, and we have to ways of accomplishing this:
- When the resource is online, use Message Carbons
- When the resource is offline and reconnects, use MAM
So I was thinking: what if MAM allowed some kind of long polling, the
way HTTP has popularized it, to accomodate for the online case ?
A client would send
<iq type='set' id='juliet1'>
<query xmlns='urn:xmpp:mam:0' queryid='f27' longpolling='true' timeout='300'>
Note the "longpolling" and the "timeout" attributes.
If I have new messages, the server responds now.
If I don't have new messages and the server doesn't understand these
attributes, it responds now with no new messages (of course the
namespace could (or even should) be changed to reflect a change in what
attributes are accepted, but at least a working MAM implementation
deployed today wouldn't break)
If I don't have new messages and the server understand these attributes,
it would hold the query open until messages arrive (or the timeout
expires). Then a response is sent, prompting the resource to send
another long-polling request.
This approach has, of course, problems:
- the server needs to keep a query on hold, contrary to message carbons
where the server just shoots messages to resources as they arrive.
- this only deals with archivable messages, and as Matthew pointed out
there are use cases where non-archivable messages should be "forked"
- every message a resource sends or receives as "standard" operations
will trigger a batch to be sent (easy rules could be implemented on
the server to prevent this, though) (this is an issue more with MAM
itself than with the current longpolling proposition)
- I have absolutely no idea about the median message rate of other
people (I barely use my account) and if this would be a viable
approach to "streaming" messages
But I believe it has some interesting points:
- the most interesting to me is that it allows implementors to focus on
a single XEP. A criticism of XMPP I see is that as a developer you can
easily get lost in the forest of XEPs. Having a single XEP for both
offline and online cases would make things a lot simpler
- longpolling is a well-understood mechanism for a low-bandwidth syncing
- AFAICS, it responds favorably to requirements enumerated in Message
Here's an even crazier idea: instead of (or besides) a "longpolling"
attribute, use a "streaming" attribute. When the server sees this, it
automatically responds with the first
<iq type='result' id='juliet1'/>
to acknowledge it has received the query, and leaves it open like that;
when messages arrive, they are sent (still with the <forwarded>
encapsulation, of course) to the resource; when no messages has been
received for the last x seconds, the server sends the
<fin xmlns='urn:xmpp:mam:0' queryid='f27'/>
so that connections aren't held for too long and can be re-built cleanly
from scratch. It's interesting to see that this would technically be a
correct behavior from the server under the current spec (ie there is no
"immediacy" specified, much like no "immediacy" allowed HTTP
implementors to create long-polling, chunked transfer encoding and
friends), even though clients would probably behave weirdly if a server
This all could look like it's overriding the forking rules of Core to
just "shotgun" the messages to every resource, but there are 2 very
- it is resource-driven. A resource cannot accidentally receive
- a resource clearly knows if it was the intended recipient or if it was
just forwarded a message
This is just an idea I throw in the mix, with no code or data to back it
but I believe we can do something here. What do you think of it ?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 343 bytes
Desc: not available
More information about the Standards