[Standards] Advancing XEP-0280 Carbons

Matthieu Rakotojaona 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’.
> /K

Hey everyone,

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'>
    <field var='start'>

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"
  to resources

- 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
did that.

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
important distinctions:
- it is resource-driven. A resource cannot accidentally receive
  forwarded messages
- 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...
Name: signature.asc
Type: application/pgp-signature
Size: 343 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150402/741ee800/attachment.sig>

More information about the Standards mailing list