[asterisk-dev] [Code Review] New application JabberReceive, implement SendText in chan_gtalk and chan_jingle

[Philippe Sultan]

> After some thought, I'd have to agree with Russell on this as well -
> there needs to be some way to capture messages that would be sent
> prior to the JabberRecieve being called.

Agreed too :).

> [note: the next two paragraphs are the start of what will become a
> very, very long set of religious discussions and gnashing of teeth and
> tearing of hair]
>
> Why?  Because I suspect that this will almost immediately become
> another API method for Asterisk.  It's an ugly, horrible, nasty
> hackish API but guess what - it'll work for most people doing
> lightweight interactions who are already using Jabber.  Machine-to-
> Machine interactions via XMPP is becoming common, and therefore the
> responses back from JabberSend will be lightning fast in many
> instances, and even the time it takes for a few dialplan events may be
> too long to correctly receive an inbound reply from an outbound
> message.  At the very least, the implementation that gets shipped
> first should be able to handle immediate responses to transmitted
> messages that may be generated by other systems otherwise the first
> impressions will be the last impressions someone gets on using this
> method, and it will create bogus summaries and manual pages that will
> be difficult or impossible to correct later - "You can't use the
> JabberSend/JabberReceive apps in Asterisk for fast responses because
> they will lose messages." would be an example of what I do NOT want to
> see.  There will certainly be problems with M2M systems using XMPP in
> this way, but such a significant one I think we should avoid on our
> first step into the minefield.
>
> Of course, an API should have the ability to create actions in a
> system, but the elements Russell mentions (global receipt of XMPP
> messages) makes that a fairly simple jump.  My opinion is that XMPP
> messages should be received globally on any JIDs registered in
> jabber.conf, and then should execute in the dialplan on a per-
> registration context (just like any other channel) using the
> registered JID as the $EXTEN, using the remote JID as the caller ID,
> and setting the text value as a dialplan variable.   But... one step
> at a time, I suppose.  :-)

That's really interesting, but wouldn't you loose the ability to call
JabberReceive within any place in the dialplan then? This is something
that needs to be investigated.

> Philippe - I understand that it works now the way you have it, but
> would it delay implementation significantly?  Are you on a roll, and
> could you keep that momentum going to add the pre-buffering or global
> receipt that has been discussed above?  I think there is an
> opportunity to have a big leap in functionality of Asterisk, and it's
> your code that's at the heart of that advancement.

No problem, I'll come up with the new implementation as soon as
possible. Plus, given the way messages are stored (e.g. in a structure
within the XMPP client), your suggestion of including the account JID
we're listening messages on becomes mandatory :)

Have a nice week end,

Philippe