[GRLUG] XMPP Proxy/Middleware Service?

[Adam Tauno Williams]

On Wed, 2009-05-27 at 16:10 -0400, Ben DeMott wrote:
> I'm not sure I understand the question exactly ... Do you want a
> client based solution, or a server based solution?

A three tier solution.  There needs to be a middle layer that maintains
the stateful connection for the stateless client (which is what a web
browser is).  This is pretty standard kind of stuff:  site instructs the
service to initiate a connection and receives some kind of auth token
that can be stored in the web session in order to communicate with the
same session on the next event.

> Do you want the client (web browser) to query the web server that then
> in-turn queries a central XMPP Server
> Why would a daemon need to run when PHP has a wrapper for Unix Sockets
> - PHP can do this directly and quite efficiently with one of several
> libraries that are available for XMPP Services.

No, PHP can't do it.  PHP scripts fire when requested,  they cannot
maintain a connection to the XMPP service,  therefore there is no useful
presence.  

> If you are using PHP as the proxy to query an XMPP Server on the
> clients behalf and you need a more robust or efficient client - I
> would suggest implementing your own client using Jquery and Json -
> json markup is much lighter weight than xml (jabber/xmpp) - especially
> to the browser... 

We've done exactly that.  It does not work effectively.  Every browser
stinks at doing GC for long lived Javascript and they are very
inconsistent concerning the order in which they initialize the runtime;
what works perfectly on a very fast machine will fail with a Javascript
error on a slow machine - or vice versa.  Also on page reloads (or even
when switching windows/tabs to the same site) the connection must be
suspended and resumed, which only works about 95% of the time; both IE
and FF occasionally start a new connection instead of resuming the
previous connection [rather than throwing an error - which one would
except if they couldn't perform the requested operation].  This
drop/reconnect causes [correctly] a logout/login event regarding XMPP
presence - so user's see a constant stream of "so-and-so logged out;
so-and-so logged in".

We use allot of AJAX tech but this just pushes it too far, and as I said
it "works";  but there is a long distance between "works" and "works
well". :)   

> The last option is using a Flash client which wouldn't be too hard to
> implement using XIFF.

Yep, thought about that.  But we've opted against flash as it is a real
support headache (we just finished removing our last flash dependency).

> As far as a well rounded boxed opensource solution that's going to
> work robustly on an intranet - I don't know of such a thing.

Surprisingly I think your correct.  But on the other hand not so
surprising.  While there is allot of XMPP/Jabber stuff floating about
most of it falls into the barely-works category.  It does appear that
for J2EE environments people map presence events to JMS events which is
a pretty neat idea; but not helpful for us stuck out in the wasteland
that is PHP.

Unfortunately this is also hard to google since the terms are all pretty
general purpose.