[Standards] Re: Inband Images
jd.conley at coversant.net
Wed Mar 28 21:41:14 UTC 2007
> On Mar 28, 2007, at 22:21, Ian Paterson wrote:
> > Yes, the data: URI protocol is only supported by the Firefox and
> > Opera browser rendering engines. So Web clients could only support
> > Inband Images if the client is opened inside one of those two
> > browsers.
> I just had an idea: Maybe the web client could convert them to
> regular images on the fly? The sender wouldn't notice anything.
> That's more like a workaround, but it could work.
> Larger images would use an approach similar to the one used in HTML
> mails, the message packet would also include a hash to avoid doing
> the same file transfer multiple times.
> Keep in mind that file transfers take 1-2sec to set up best case, so
> it should be avoided at all cost.
I agree that the hash is a must.
File transfers don't have to take that long, especially for small
things. There's no reason to not just say "ok, the file is less than
1MB, let's just use our IBB". With the IQ based IBB this can even be
flow controlled. Also, at the initiation of a conversation you can
establish a long lived IBB that is available for things such as
emoticons. If we're writing new protocol we might as well add this
concept (ok maybe someone did this already in a XEP) of a more long
lived stream -- aka Direct Connect -- that can take more than one file
request in the queue without having to tear it down.
If you simply MUST have a real peer-to-peer connection, negotiate
something in the background and use it for subsequent requests.
Also, we should definitely not limit the URI's in the img tags to the
sender of the message (I don't think anyone implied this, but I just
want to make sure). I envision people running bots on the network to
browse and subsequently serve up emoticons via bytestreams. Especially
when they get more interesting, your peers aren't going to have enough
bandwidth to upload you an emoticon.
More information about the Standards