> 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 _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
