Yes, for a chat client it is great. Messages in chart are much less frequent. I am not sure XMPP is the best for character by character operations.
One thing to note is that wave doesn't even "really" use XMPP as chat programs do. XMPP Chat puts chat messages in XML. Wave uses XMPP as a messaging envelope. The actual operations are sent over in a binary coded protobuf. So, most people would not argue XMPP as an established chat protocol. However, wave is not chat. ~Michael On 6/12/13 12:39 PM, "Thomas Wrobel" <darkfl...@gmail.com> wrote: >Just a small comment; Facebook uses XMPP for its chat client too. Its >hardly industry toxic. In chat clients at least its practically >industry standard. > >On 12 June 2013 12:14, Michael MacFadden <michael.macfad...@gmail.com> >wrote: >> 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 >>>> >> >>
