[JDEV] XHTML Inband Images update

[Richard Dobson]

> At first glance it looks okay.  This might be a good way to offset the
current
> 'drop down emoticon' trend, people who want a specific image can send the
> image, and emoticons can return to being purely pretty-printed text like
> they're supposed to be.

The main reason is so you can include arbitary images without having to
reference them on an http server will all the problems that entails, but yes
it can be used for custom emoticon graphics as well as other arbitary images
you wish to display to someone in a chat, but it is designed to be flexible
so that it is not restricted to images and could perhaps be used for other
things like sound effects.

> I'm not sure how useful it is to do a disco on the object.  If an <img/>
tag
> was used, it has to be an image/* of a certain restrictive set (e.g.
> image/svg won't work in the <img/> tag, also if you're interested in the
size
> of the image for restricting download of large images, you could look at
the
> width and height attributes which should be on the image also.  And don't
> forget the 'alt' attribute!  And maybe also 'title', if you want it rich.

The file property discovery protocol is used to discover the actual
properties of the file in question, relying the width and height attributes
of an img tag I dont think would be appropriate because they do not
necessarily represent the actual dimensions of the image in question, just
the dimensions you would wish it be rendered at. Also that info is not
included in the <obj/> tag in the message to reduce waste of bandwidth as
since you will cache images the first time you get them you dont need that
info the next time you are sent that image (because you already have it
cached).

> But to be truly flexible, you would need to use <object/> instead of
<img/>,
> to enable all sorts of objects in the future which currently wouldn't
work.
> Not to mention you're making it more compatible with the upcoming XHTML
2.0.

Use of the object tag is specified as MUST NOT be supported in the XHTML-IM
specification in JEP-0071 so we cannot use that.

> One other thing, isn't 'embedded' spelled with an 'e' usually?  I hope the
'i'
> in 'iobj' isn't to stand for '*i*mbedded'. ;-)

No it originally stood for inline (hence the title), plus ive look it up on
dictionary.com and imbedded does seem to be a valid spelling, although yes I
think it is usually spelt with an e.

Richard