(no jokes this time ;)
Since one of the most requested features for mobiles is compression
and binary xml is often proposed for this, I've tried to summarize few
of the points in my blog (http://blog.bluendo.com/ff/real-binary-xmpp)
The point (upon which we had rather consensus in the past) is
Fabio Forno wrote:
(no jokes this time ;)
Since one of the most requested features for mobiles is compression
and binary xml is often proposed for this, I've tried to summarize few
of the points in my blog (http://blog.bluendo.com/ff/real-binary-xmpp)
The point (upon which we had rather
Sorry for the delayed reply, I'm slowly catching up on email.
Dave Cridland wrote:
On Wed Feb 27 16:06:23 2008, Peter Saint-Andre wrote:
Fabio Forno wrote:
Though sending roster diffs helps. There is a new possible approach
I've found only after the discussion we had: use just roster push,
Hi,
On Feb 27, 2008, at 4:06 PM, Peter Saint-Andre wrote:
Fabio Forno wrote:
On Wed, Feb 27, 2008 at 5:06 AM, Peter Saint-Andre
[EMAIL PROTECTED] wrote:
2.1 What people have done or suggested
- fast reconnection
- pipelining of stream negotiation exchanges (Tony Finch)
- don't
On Wed Feb 27 20:56:28 2008, Fabio Forno wrote:
On Wed, Feb 27, 2008 at 6:52 PM, Dave Cridland [EMAIL PROTECTED]
wrote:
3) Client says I have the roster as of this point in time.
Server
either says Here's the changes or Here's the whole roster,
depending on whether it can find all
On Wed Feb 27 18:01:30 2008, Tony Finch wrote:
On Wed, 27 Feb 2008, Dave Cridland wrote:
I also have a fondness for modified strictly increasing
timestamps, but
implementors need to appreciate that computer clocks go
backwards, so they
need to remember to handle odd cases like that by
Hi,
On Feb 27, 2008, at 9:19 PM, Alexander Gnauck wrote:
Fabio Forno wrote:
I like this one, since it always has a backup when no sinchronization
is needed. Moreover the server can store only a window of changes,
and
send the whole roster if the last known by the client is too old
+1, I
On Thu, Feb 28, 2008 at 10:58 AM, Dave Cridland [EMAIL PROTECTED] wrote:
No, not too old, as such.
Let's call our strictly increasing sequence a modseq. Every time a
roster item gets pushed, the server includes the current value of the
modseq and increments the modseq. We'll call this
Fabio Forno wrote:
On Wed, Feb 27, 2008 at 5:06 AM, Peter Saint-Andre [EMAIL PROTECTED] wrote:
2.1 What people have done or suggested
- fast reconnection
- pipelining of stream negotiation exchanges (Tony Finch)
- don't retrieve roster (but this doesn't really help)
Though sending
On Wed Feb 27 16:06:23 2008, Peter Saint-Andre wrote:
Fabio Forno wrote:
Though sending roster diffs helps. There is a new possible
approach
I've found only after the discussion we had: use just roster push,
that must implemented regardlessly any optimization. The client
asks
for the
On Wed, Feb 27, 2008 at 5:06 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote:
Yes, we have roster pushes so it seems like a good idea to use them (in
general I think we should make intelligent use of everything we've
already defined, such as presence and rosters and roster pushes and so
on
On Wed, 27 Feb 2008, Dave Cridland wrote:
I also have a fondness for modified strictly increasing timestamps, but
implementors need to appreciate that computer clocks go backwards, so they
need to remember to handle odd cases like that by letting time catch up -
just using a few ms later than
Dave Cridland wrote:
2) Client says I have the roster as of this point in time. Server says
Here's all the changes since then..
This is obviously the best option in terms of efficiency, but it, too,
has problems. The key issue is that roster entries won't die - instead,
they'll be maintained
Alexander Gnauck wrote:
Dave Cridland wrote:
I also have a fondness for modified strictly increasing timestamps,
but implementors need to appreciate that computer clocks go backwards,
so they need to remember to handle odd cases like that by letting
time catch up - just using a few ms later
Peter Saint-Andre wrote:
Alexander Gnauck wrote:
for this reason I would prefer a versioning of the roster, so I client
can just tell the server I have version 235241 of the roster, let me
know if this is the current roster or send me the changes otherwise.
That seems best to me, too. Heck,
On Wed, Feb 27, 2008 at 6:52 PM, Dave Cridland [EMAIL PROTECTED] wrote:
3) Client says I have the roster as of this point in time. Server
either says Here's the changes or Here's the whole roster,
depending on whether it can find all deletions.
This is basically addressing the shortfall
Fabio Forno wrote:
I like this one, since it always has a backup when no sinchronization
is needed. Moreover the server can store only a window of changes, and
send the whole roster if the last known by the client is too old
+1, I don't think we want to keep all roster revisions from the
On Wed, Feb 27, 2008 at 10:19 PM, Alexander Gnauck
[EMAIL PROTECTED] wrote:
Fabio Forno wrote:
I like this one, since it always has a backup when no sinchronization
is needed.
s/is needed/succeds/
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: [EMAIL PROTECTED]
] On Behalf Of ext Joe Hildebrand
Sent: 19 February, 2008 17:01
To: XMPP Extension Discussion List
Subject: Re: [Standards] mobile optimizations
Could this be added to XEP-198? Basically a pause command
that would cause stuff to get buffered on the server. There
would need to be an ack that comes back
: 19 February, 2008 17:01
To: XMPP Extension Discussion List
Subject: Re: [Standards] mobile optimizations
Could this be added to XEP-198? Basically a pause command
that would cause stuff to get buffered on the server. There
would need to be an ack that comes back to avoid races
On Tue Feb 19 15:00:36 2008, Joe Hildebrand wrote:
Could this be added to XEP-198? Basically a pause command that
would cause stuff to get buffered on the server. There would need
to be an ack that comes back to avoid races. Additionally, I
could imagine the thing doing the buffering
On Feb 19, 2008 1:51 AM, Alexander Gnauck [EMAIL PROTECTED] wrote:
the Jaiku guys do stuff like this on their mobile client. They have lots
of experience with this and gave a impressive speech about this topic
last year at the FOSDEM.
A extension for this would be very nice. So I could put
On Feb 16, 2008 6:10 AM, Peter Saint-Andre [EMAIL PROTECTED] wrote:
It would be good to analyze the relative percentage of presence to
messages. My sense from watching the XML console in Psi is that most of
the noise is presence.
In general I think it might be difficult to determine which
Could this be added to XEP-198? Basically a pause command that would
cause stuff to get buffered on the server. There would need to be an
ack that comes back to avoid races. Additionally, I could imagine the
thing doing the buffering could toss old stale presence stanzas when
new ones
How important is session startup latency for mobile XMPP? The motivation
for SMTP quickstart was to make sending email faster. Sending email is
quite an interactive action (though good client software can hide the
latency). The equivalent in XMPP is sending a message on a connection
that's already
Peter Saint-Andre schrieb:
Hi Alex, that's helpful information. We have compression enabled at the
jabber.org service so perhaps you could get some new numbers with your
account there. :)
yes I can do that. The code must be still somewhere on my hd. I do a
search ;-)
Alex
On Fri, Feb 15, 2008 at 8:39 AM, Alexander Gnauck [EMAIL PROTECTED] wrote:
I posted some stats in another thread before:
http://mailman.jabber.org/pipermail/jdev/2006-November/024552.html
They were not from a very long lived session, but I think they show that
some stanzas compress very
On to, 2008-02-14 at 13:08 -0700, ext 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
On Feb 14, 2008, at 4:03 PM, Dave Cridland wrote:
I could stick XEP-0138 in it quite quickly I think as a test).
Exactly. Ease-of-implementation should still be a goal of ours.
--
Joe Hildebrand
On Fri, Feb 15, 2008 at 5:06 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote:
Dave Cridland wrote:
Fast resynchronization is somewhat more complex - roster optimizations
is one area we need, and I think I see a clear way of doing this.
Whether it's implementable by everyone I don't know.
On Thu, 14 Feb 2008, Peter Saint-Andre wrote:
3. Fast reconnect to avoid TLS+SASL+resource-binding packets.
I should note that my quickstart approach does not really avoid these
steps, but instead overlaps them. You'd still transfer the same number of
octets. However if you deploy all the
On Fri, 15 Feb 2008, Dave Cridland wrote:
Both are really scary. I've always been a big fan of the detailed round-trip
analysis at the end. I'm hoping Tony will notice this thread and do something
similar for XMPP.
3920bis already has some nice examples which provide a great starting
point
Alexander Gnauck wrote:
Fabio Forno schrieb:
... Anyway I can anticipate that with zlib the size of a whole
message stanza is often shorter or minimally longer than the
uncompressed body alone: do we really need better performance?
I posted some stats in another thread before:
Dave Cridland wrote:
On Fri Feb 15 11:36:01 2008, Aki Niemi wrote:
Is there currently a way for the client to put its connection into
dormant mode. For example, when my phone is in my pocket with the screen
locked, keeping the roster's status updated seems unnecessary. Yet, the
connection
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,
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.
+1 for the fast reconnect
On 2/14/08 3:08 PM, Peter Saint-Andre [EMAIL PROTECTED] 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.
On Thu, Feb 14, 2008 at 9:39 PM, Dave Cridland [EMAIL PROTECTED] wrote:
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
Actually the W3C binary XML standard when compared to traditional
compression standards like Zip is significantly better. The binary
conversion process also compresses file.
You might want to read:
http://www.w3.org/XML/EXI/
http://www.w3.org/TR/2007/WD-exi-measurements-20070725/
Dave,
take a look at http://www.agiledelta.com/w3c_binary_xml_proposal.html and
http://www.idealliance.org/papers/xml02/dx_xml02/papers/06-02-04/06-02-04.pd
f. The W3C spec is based on Agile Delta¹s EfficientXML. the data I have seen
on EfficientXML indicate that it many times more efficient on
On Thu, Feb 14, 2008 at 08:39:29PM +, Dave Cridland wrote:
On Thu Feb 14 20:08:53 2008, Peter Saint-Andre wrote:
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
(Hey, where did that space come from in the subject line?)
On Thu Feb 14 22:06:19 2008, Boyd Fletcher wrote:
1362 byte message strongly typed
WinZip 3.13 times smaller than original
EfficientXML 75.67 times smaller than original
980 byte message loosely type
WinZip 1.6 times smaller than
On Thu, Feb 14, 2008 at 11:06 PM, Boyd Fletcher
[EMAIL PROTECTED] wrote:
1362 byte message – strongly typed
WinZip 3.13 times smaller than original
EfficientXML 75.67 times smaller than original
980 byte message – loosely type
WinZip 1.6 times smaller than original
Efficient XML 8.45
On Fri, Feb 15, 2008 at 12:03 AM, Dave Cridland [EMAIL PROTECTED] wrote:
To my mind, the figures and graphs there suggest that improvements
over DEFLATE will be marginal at best for our kind of data.
That's my point as you can read in my other mail, benchmarks are too
sensitive to the nature
On 2/14/08 5:57 PM, Fabio Forno [EMAIL PROTECTED] wrote:
On Thu, Feb 14, 2008 at 11:06 PM, Boyd Fletcher
[EMAIL PROTECTED] wrote:
1362 byte message strongly typed
WinZip 3.13 times smaller than original
EfficientXML 75.67 times smaller than original
980 byte message
On Fri, Feb 15, 2008 at 12:10 AM, Boyd Fletcher
[EMAIL PROTECTED] wrote:
I agree that protocol improvements are in order. But XMPP data was looked
at but some of the folks on the W3 committee as example data and the
compression was significant. There has also been some internal testing in
On Thu Feb 14 22:49:20 2008, Peter Saint-Andre wrote:
On Thu, Feb 14, 2008 at 08:39:29PM +, Dave Cridland wrote:
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 -
Fabio Forno schrieb:
... Anyway I can anticipate that with zlib the size of a whole
message stanza is often shorter or minimally longer than the
uncompressed body alone: do we really need better performance?
I posted some stats in another thread before:
48 matches
Mail list logo
