On Mon Nov 5 11:51:16 2007, Michal 'vorner' Vaner wrote:
On Mon, Nov 05, 2007 at 11:40:18AM +0000, Dave Cridland wrote:
> A new top-level stanza of (say) <blob/>, which much the same
attributes as > any other routable stanza, but also has an octet
count. Upon receipt, the > XML processing is suspended, and the
following octets are handled verbatim:
>
> <blob from='[EMAIL PROTECTED]/court'
to='[EMAIL PROTECTED]/court' > octet-count='4'/>1234
You probably can not do that with any reasonably out-of-the-box XML
parser. Furthermore, you may need to pass the stream trough charset
decoder to get some internal stringish representation. This will
make it
mad. So, in short, I strongly disagree here.
An alternate would be to encapsulate both XML and blobs, which'd be
an even more radical departure. (And look impressively like BEEP). So
for each chunk, you'd predefine how long it was, and whether it was
blob or XML. (Yes, there are defined formats for doing so, which have
been mentioned on this list before).
Or - just a thought - we could pinch IMAP's synchronizing literals:
C: <blob ... octet-count='4096' sync='true'>
S: <blob ... sync='go=ahead'>
C: [4096 octets of blob]
C: [... more XML ...]
This adds a round-trip to all blob-stanza transfers, of course.
(Although it's a hop-by-hop RTT, not an end-to-end RTT). No reason
that couldn't be an option, too, so implementations which can cope
with non-synchronizing blobs can say so. (I personally suspect many
will be able to).
But you may like SCTP or how's the protocol called and push the
blobs
out-of-the stream.
Yes, but I doubt that'd get much traction. SCTP stacks are rare
enough, and especially so in those areas where the base64 encoding
overhead of (say) IBB makes a serious difference. (Yes, you could
encourage all XMPP clients to include a SCTP/UDP implementation, but
that's a heavy requirement, I'd have thought).
Or another "blobby" TCP connection to the server. (if
you really want to send these things trough the server).
Well, I think increasingly we need to send these things via the
server. In fact, we're doing so quite a bit - the question is, do we
care about the base64 overhead enough that we want to address this.
Another option would be to setup a distinct connection (and protocol)
for routing blobs, and so send them through the server, yet not
in-band. I'm not comfortable with this, because it means essentially
duplicating all security information, and maintaining synchronization
between two distinct streams.
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
