ubuntu-push-devs team mailing list archive
-
ubuntu-push-devs team
-
Mailing list archive
-
Message #00072
Re: Ejabberd
On Tue, 2013-10-01 at 15:38 -0700, Peter Saint-Andre wrote:
> [ Joined late, replying to the first message I see. ]
Thanks for joining in Peter.
> On 10/1/13 11:38 AM, Ted Gould wrote:
> > Hmm, perhaps it would be best to look at a different XMPP
> > implementation then? I guess storage seems like something
> > different ones would do differently.
>
> Yes.
It seems like the critical issue here is how XMPP implementations deal
with scaling. Do you know how that's typically done? Is that
per-implementation or are there some standard strategies?
> >> Reliability of delivery: The XMPP Core spec says:
> >
> > Perhaps this my misunderstanding of the low level goal here, but I
> > thought we were trying to leave the radios off as much as possible.
> > And it seems to me, that means no long running TCP connections as
> > you don't want to have the radios on.
>
> My understanding from some mobile telephony engineers I talked with
> years ago (folks from Nokia) is that mobile devices can actually deal
> with long-running TCP connections quite well. There's magic involved.
Wow, I can imagine. Perhaps some sort of multi-path TCP packet or
something like that.
> I'm not necessarily pushing XMPP here because it's not the answer for
> everything. However, there are good open-source implementations for
> both servers and libraries. I'll spend some time digging into the list
> archives here so that I can understand your requirements a bit better.
Thanks for taking a look. I'm not sure we're entirely sure of all the
requirements we could have yet, we're mostly focused on getting some of
the major use-cases out of the way, along with making sure we don't
screw ourselves for the future when we need something more complete.
Ted
Attachment:
signature.asc
Description: This is a digitally signed message part
Follow ups
References