incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave <>
Subject Re: Future of Apache wave [Was: Re: Advantages of P2P messaging?]
Date Wed, 12 Jun 2013 01:32:11 GMT
On 12/06/13 01:10, Joseph Gentle wrote:
> ... Don't mind me - I get a little ranty :) 

I've a thick skin ;-)

On 12/06/13 00:54, Joseph Gentle wrote:
> On Tue, Jun 11, 2013 at 4:08 PM, Dave <> wrote:
>> Protobuffs in XMPP might not be the most elegant wire protocol, but they're
>> both proven, solid messaging technologies.
> They are???

Well, independently at least. ;-) Not that I'm particularly a fan of 
XMPP, but I've not seen anything that indicates xmpp as a protocol 
causes any of wave's headaches.  To the contrary, the XMPP layer is 
quite uninteresting - we just stream xml down a socket.

The more complex bit is the blobs we put in the XML, when we send the 
blobs and where we send them - all of which is independent of the xmpp 
pipe they get sent down.

> Because you know, wave federation has _never_ worked reliably. I gave
> a talk back in 2010 explaining how to set up federation in a virtual
> machine. I practiced my talk a few times, and sometimes (with exactly
> the same certificates, configuration files, software & OS) it simply
> wouldn't work. Why not? Two and a half YEARS have passed and still
> nobody knows.

Well, there's a bunch of ways it can go wrong, but most of them are 
nothing to do with the technologies.

> XMPP server extensions are supposed to be a standard, but last I
> checked, only a couple of XMPP servers even half-work with wave in a
> box. Why? Because everyone has implemented the XMPP standard in
> slightly different, incompatible ways. Are the bugs in WIAB itself or
> in the XMPP servers? I don't know! The broken behaviour is so
> complicated that nobody understands how it works, let alone what the
> problem is.

Last I heard, quite a few people use xmpp for messaging and S2S with a 
bunch of different implementations quite successfully. The component 
extension isn't one of the more common, but it's also purely an 
implementation decision within wiab.

Maintaining the wire protocol doesn't mean we can't change the 
implementation - for example I've been experimenting with an embedded 
xmpp server (Apache Vysper), rather than the external component interface.

> Its pretty clear that we can't maintain federation based on an XMPP
> extension. We can't even fix obvious, repeatable bugs.

I might be the only one, but it's not clear to me - nor have I seen a 
coherent argument about _why_ that would be the case. As far as I'm 
aware, very little effort has been put into maintaining federation. 
Until recently I think the last time it was tried was a year ago - but 
thanks to a couple of tweaks by Ali, the recent attempts were reasonably 
successful (i.e. it seems to federate largely Ok, but the webclient 
needed a little massaging)

> And we don't even use XMPP for anything! I thought we'd at least use
> the XMPP server to log in users but we don't even do that - we
> maintain our own user list.

Well, we don't use it for much. It does remote service discovery, stream 
encryption and a very poor anti-spoofing mechanism (which is still 
effective). Plus the core S2S bits in the wave wire protocol are widely 
implemented with many cross platform libraries and servers [1]

I mean, if we were implementing this protocol from scratch, I doubt I 
would advocate xmpp, but it's what we've got and from what I've seen not 
at all deserving of the bashing it sometimes gets :-]

> Its like we're using XMPP as a buggy, hard
> to configure TCP stream that nobody understands. I guess at least it
> checks our SSL certificates. Whoopie.

Prosody at least is fairly simple to configure, more so with the ant 
task Bruno has just contributed (to generate prosody config) and we 
could improve that even further if we decided to ship an xmpp server.

> I don't understand all the hero worship of XMPP. Has anyone else tried
> to actually read the spec?
> There's a reason Google, Apple, Facebook,
> etc don't use XMPP. Its not because they hate freedom. Its because
> XMPP is awful.
The same is true of most specs!
> If you want to convince anyone that its a 'proven, solid messaging
> technology', you should start by fixing our XMPP extension code.

Are you aware of any specific defects to report? There's slim pickings 
in jira: [2]

Personally, I'd prefer to eliminate the external dependency by either 
bundling or embedding an xmpp server when we distribute wave.  But 
there's plenty we can do to make deployment with federation easier, 
without needing to throw away the wire protocol.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message