Google Androïd SDK not XMPP compliant ?

On Thu, Feb 14, 2008 at 10:12 AM, Lee Dryburgh
<dryburghlgmail.com> wrote:
> I think this just stands to open the whole binary
encoded debate once
>  again. I'm too much of a coward to be caught in the
crossfire so I
>  will duck out and not give my opinion.

Once I was one of those baldly standing for a binary binding
for
mobiles (and other devices with limited capabilities). Then
I started
doing some private tests and I realized that the situation
is at least
a bit controversial:
- a fully extensible xml binding is not easy when dealing
with streams
and not documents, since you don't know in advance the
dictionary of
tokens that will be used; a solution with a fixed grammar
(e.g
jabber:client namespace e few others) would be really a step
back in
the xmpp tradition of extensibility
- compression is not as bad as I thought and if time to
market is
essential that's the only viable solution
- if you do such an operation for mobiles you have to
consider several
other optimizations that are not less important: the ability
to resume
a session with something like a cookie (for this reason a I
like
bosh), limiting the initial roster get / presence burst /
the ability
to keep the session responsive when disconnected but not
offline (e.g.
my session is still alive, but the phone is not reachable in
that
moment: some applications may want to know that the message
could be
delivered with some delays though they see you online and
available)

>  Additionally I've made a request to interview him and
if there is a
>  consensus over questions to ask, I can certainly
consider it.

For my concern, I'd like to know whether they just taking
the binary
xml path and with which of extensibility, or they are
approaching the
mobile problem addressing the whole class of problems I've
listed

-- 
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: ffjabber.bluendo.com

On Thu, Feb 14, 2008 at 1:45 PM, Alexander Gnauck
<gnauckag-software.de> wrote:

>  see also my comments in the jdev thread, I think we
should all hop one
>  one thread 

yep ;)

>  http://mail.jabber.org/pipermail/jdev/2008-Februa
ry/026157.html
>
>  I have done lots of mobile programming and tests in
the past. And it
>  really performs very well. ZLib does not need much CPU
and the
>  compression ratio with XMPP XML is amazing.
>
>  When somebody wants to have this binary Xml, which I
think is not a bad
>  idea, then plug it into XEP-0138.

agree, my point of view is just that binary xml is not the
only issue
with mobile terminals, there is a wider set of problems to
be
considered for optimizing the connection (some such as
stanza
acknowledgments are already there, though I don't know how
many
servers handle them, others such as limiting the initial
roster and
presence burst aren't addressed well now)

-- 
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: ffjabber.bluendo.com

On Thu Feb 14 08:55:29 2008, biojab biojab wrote:
> http://code.google.com/android/migrat
ing/m3-to-m5/m5-api-changes.html#gtalk

Indeed - I think their reasoning is flawed, and their
solution will  
likely be broken.

I commented on this (and inadvertantly duplicated many of
Fabio  
Forno's observations, as well as Alex Gnauck's) in my blog,
but the  
thing that surprises and disappoints me most is the complete
surprise  
this represents to those of us who are involved in open
standards,  
and were under the impression that Google cared about them
too. I  
think in the medium term this is likely to blow up in their
faces.

I'm aware that there are several mobile client developers
present -  
if there's any good to be found here, a concrete proposal
for mobile  
XMPP would be an excellent step forward. I'm assuming that
XEP-0138,  
XEP-0198, and probably some sort of roster optimization
would all be  
useful, for example, but best practises for servers aiming
to  
optimize for mobile clients (perhaps by buffering the
initial  
presence surge to gain better compression, for example)
would be  
useful too.

Dave.
-- 
Dave Cridland - mailto:davecridland.net - xmpp:dwdjabber.org
  -
acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Dave Cridland wrote:

> I'm aware that there are several mobile client
developers present - if
> there's any good to be found here, a concrete proposal
for mobile XMPP
> would be an excellent step forward. 

Sounds like a good topic of discussion at the devcon next
week.

> I'm assuming that XEP-0138,
> XEP-0198, and probably some sort of roster optimization
would all be
> useful, for example, but best practises for servers
aiming to optimize
> for mobile clients (perhaps by buffering the initial
presence surge to
> gain better compression, for example) would be useful
too.

Here's a list of things we might talk about:

1. Recommendations regarding when to use the TCP binding and
when to use
the HTTP binding (BOSH).

2. Compression via TLS or XEP-0138 (use it!). Also binary
XML as a
compression mechanism.

3. Fast reconnect to avoid TLS+SASL+resource-binding
packets.

4. ETags for roster-get (see XEP-0150, let's resurrect
that).

5. Advisability of presence-only connections (no roster-get,
just send
presence and whatever you receive is nice).

Anything else?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

On Thu Feb 14 20:08:53 2008, Peter Saint-Andre wrote:
> Here's a list of things we might talk about:
> 
> 1. Recommendations regarding when to use the TCP
binding and when  
> to use
> the HTTP binding (BOSH).
> 
> 2. Compression via TLS or XEP-0138 (use it!). Also
binary XML as a
> compression mechanism.
> 
> 
I've never been all that convinced about binary XML forms.
They work  
to a degree with the highly fixed XML in, for example,
SyncML, and  
they're pretty good at compressing individual stanza-like
objects  
over SMS for things like OMA EMN (Email Message
Notification, or  
something - I've long since forgotten what these acronyms
stand for),  
but for long-running streams I'm under the impression that
studies  
show it'll be outperformed.

So if you're a big fan of Binary XML formats, please bring
along your  
figures. 


> 3. Fast reconnect to avoid TLS+SASL+resource-binding
packets.
> 
> 
Lots of work from mobile email (ie, Lemonade) is
transferrable here.  
It'd be really nice if Tony Finch was coming, since he could
talk us  
through QTLS and QUICKSTART - they're SMTP fast startup work
he did a  
while back. Very interesting, but didn't make it into the
Lemonade  
Profile itself.


> 4. ETags for roster-get (see XEP-0150, let's resurrect
that).
> 
> 
(Om. Looks quite ugly, IMHO. I'll do a counter-proposal)


> 5. Advisability of presence-only connections (no
roster-get, just  
> send
> presence and whatever you receive is nice).
> 
> 
If you can optimize the roster fetch sufficiently, this
really isn't  
required.


> Anything else?

Beer, obviously.

Dave.
-- 
Dave Cridland - mailto:davecridland.net - xmpp:dwdjabber.org
  -
acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

On Thu, Feb 14, 2008 at 9:08 PM, Peter Saint-Andre
<stpeterstpeter.im> wrote:
> Dave Cridland wrote:
>  > I'm aware that there are several mobile client
developers present - if
>  > there's any good to be found here, a concrete
proposal for mobile XMPP
>  > would be an excellent step forward.
>
>  Sounds like a good topic of discussion at the devcon
next week.

+1

>
>  Here's a list of things we might talk about:
>
>  1. Recommendations regarding when to use the TCP
binding and when to use
>  the HTTP binding (BOSH).
>
>  2. Compression via TLS or XEP-0138 (use it!). Also
binary XML as a
>  compression mechanism.
>
>  3. Fast reconnect to avoid TLS+SASL+resource-binding
packets.

together with 1) best practices for keeping the session
alive within
the connection manager when using bosh

>  4. ETags for roster-get (see XEP-0150, let's resurrect
that).

In fact I was wondering why it was forgotten..,

>  5. Advisability of presence-only connections (no
roster-get, just send
>  presence and whatever you receive is nice).

In fact we're are using this technique in our mobile client,
and there
aren't particular problems. The only problem is that we're
still
receiving a huge burst of presence, especially if in the
roster there
are many bots that are always online. It's should be nice if
the
connection were able to pack and compact presence info (not
easy since
some presence stanza may take a while before receiving it)
or extend
ETags for more volatile data such as presence.

-- 
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: ffjabber.bluendo.com