incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Wrobel <darkfl...@gmail.com>
Subject Re: Future of Apache wave [Was: Re: Advantages of P2P messaging?]
Date Wed, 12 Jun 2013 11:39:24 GMT
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.macfadden@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" <vega113@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) <
>>stenyak@gmail.com> wrote:
>>
>>> On Tue, Jun 11, 2013 at 11:38 PM, Joseph Gentle <josephg@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
>>>
>
>

Mime
View raw message