A Googler once told me that XMPP was used primarily because they already had an internal infrastructure (Gtalk) based on XMPP, they just just wanted to reuse this infrastructure. It does have its advantages in not having to re-invent the wheel.
I can also say that in a few use cases, XMPP has proven to be non-feasible due to the overhead of the protocol and it's expectation for long lived TCP connections. During the wave summit, there was an overwhelming desire to remove XMPP in favor of something more lightweight. Not much came of that. ~Michael On 6/12/13 11:09 AM, "Yuri Z" <vega...@gmail.com> wrote: >AFAIK the main idea of XMPP was to re-use the auto server discovery and to >use its secure communication. With lighter approaches - like HTTP you >would >need to figure out how to relate a federating user from example.com domain >to the actual wave server that can run at sub domain wave.example.com. > > >On Wed, Jun 12, 2013 at 10:13 AM, Bruno Gonzalez (aka stenyak) < >sten...@gmail.com> wrote: > >> On Tue, Jun 11, 2013 at 11:38 PM, Joseph Gentle <jose...@gmail.com> >>wrote: >> >> > I heard a story once from some developer attending a java conference. >> > >> > The theme was how to solve the challenges that Java faces in the next >> > decade - and basically everyone was talking about how to make >> > development tools scale up to work with codebases which were millions >> > of lines long. How do we manage big projects? How well does eclipse >> > scale? How do we refactor codebases that size? >> > >> > This is crazy. The right question isn't "How do we scale our tools", >> > its "How do I write less java?". >> > >> > >> I agree with you on this. The other day I was about to add half a dozen >>new >> settings to the config files (for the email-wave bot). I thought it >>would >> take 5 minutes max, something like adding lines like this: >> >> value = settingsManager.get(key); >> >> But after 20 minutes traversing the code, writing each variable many >>times >> in different files, with different syntaxes (camel case, underscore >> separators, all-caps, and whatnot) throughout several code layers, I >>still >> hadn't managed to reach the point of code where I actually wanted my >>bot to >> use the damned settings. I'm all for future-proofing the design, but I >> think that's a bit ridiculous. I don't want to imagine the fun in >>debugging >> federation and ot algorithms when they fail, if it's all written like >>this. >> >> Ali and I half-joked about going on a killing spree to halve the amount >>of >> code. I'm sure no practical functionality would be lost... :-) >> >> -- >> Saludos, >> Bruno González >> >> _______________________________________________ >> Jabber: stenyak AT gmail.com >> http://www.stenyak.com >>
