On Tue Aug 28 09:39:39 2007, Richard Dobson wrote:
I digress, but... you cannot surf and call on GPRS at the same
time, generally. This is why if someone calls a GSM phone while
you are loading a webpage, they will generally go straight to
voicemail.
Just to correct you here but they wont goto voicemail (if you are
connected to WAP using a dial up method maybe), but you can
definitely be downloading via GPRS/3G/HSDPA and still make and
receive calls, i've done it myself.
Yes, but (certainly on my phone) it cuts the GPRS while you do so.
However, it's certainly possible to have multiple data transfers
going on in a single GPRS session, but that, of course, is using this
really cool bytestream technology called "TCP". I here it's used
quite widely, these days. ;-)
automatic file pre-compression
-----
It would be handy to be able to automatically compress files before
they are transferred and then be able to specify this in the SI
negotiation allowing the receiving client to then automatically
decompress the file once it has received it, this could greatly
help with the size of file transfers and would also only need to be
done for file types that would benefit from it, i.e. you wouldn't
bother with files that were already compressed or things like audio
and video files that are likely to only get marginal gains.
If you're transferring over a compressed stream (say, a modern TLS
implementation), then it's worth noting that compression algorithms
usually contain some mechanism for identity encoding.
This is needed because files with high entropy (ones that are already
compressed) would otherwise lead to alarming expansion. This allows
for not only transparent compression, but also transparent
non-compression, and allows applications to stop trying to
second-guess whether data is compressible or not.
Interleaving different data streams will defeat this, but if a new
data stream (and thus compression state) is used for each transfer,
this will work out okay.
If you want to transfer multiple files, do so either in distinct
sessions (if you want to do so concurrently), or serially within the
same session, with an intervening flush.
As an unrelated aside, TLS in this instance would benefit from
mandatory support for anonymous cipher suites. ADH et al would be
perfect for this kind of thing.
jingle bytestream
-----
When we come to implement file transfer using jingle I would
suggest that rather than creating a brand new backwards
incompatible file transfer protocol that we simply implement a new
jingle bytestream transport just like XEP-0047 and XEP-0065 which
would allow complete compatibility with the SI negotiation but
still gets all the benefits a file transfer over jingle UDP would
bring, i.e. better likelihood of connection.
I'd be interested to here what Rob McQueen and other knowledgeable
folk would think about transferring files over ICE. I vaguely recall
there are existing mechanisms for layering SCTP over UDP, which
presumably might fit here and save a lot of work. (Not that SCTP is
quite what you want for file transfers, but it'll do).
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
