Yes, but (certainly on my phone) it cuts the GPRS while you do so.
Fair enough, mine doesn't, must be a limitation either with your handset
or your network provider (I would expect its just the handset trying to
maximize battery life and radio usage, as you arn't entirely likely to
be needing to use it while on a call rather than being a limitation of
GPRS), does yours send incoming calls to voicemail as Rachael says hers
does when you are doing GPRS transfers?
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. ;-)
LOL, although technically im pretty sure GPRS (and 3G) often uses
multiple channels in order to speed up data transfer speeds anyway.
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.
The thing is the specs (XEP-0047, XEP-0065, XEP-0095, XEP-0096) mention
nothing about using TLS over the bytestream so im pretty sure that would
break all existing implementations, whereas pre-compressing the file is
completely backwards compatible with whats being sent over the
bytestream and compatible with all receiving clients as the user will
still likely be able to decompress a zip file themselves if their client
does not support automatic decompressing.
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).
Yea but would be good if we can implement it in the most backwards
compatible way we possibly can which creating a jingle bytestreams (ala
XEP-0047/XEP-0065) spec should do, it also reuses existing work, and
even allows the reuse of the jingle bytestream in other specs (i.e. the
idea of SI) without changing anything in jingle itself.
Richard
