[Standards-JIG] avatars

Heiner Wolf wolf at bluehands.de
Fri Jul 2 11:05:59 UTC 2004


Hi,

I see, that I did omit the hashes. Hashes are important and we use them heavily exactly for what you say. My client fetches avatars from many users. This is done only if the hash does not match. (These <obj/>s were just example what I mean by harmonization. I did not propose the next protocol. They were for sure neither complete   nor correct)

Also there are obviously 2 notions of in-band here. I agree that data objects should not be in-band when something (XHTML) is pushed. In this case there should be the hash. Which is not there. I only see cid and id in  <obj xmlns='http://jabber.org/protocol/iobj'/>. But if I decide to retrieve a data object after  disco, checking for size, mime-type, etc. If I decide i want the data object then I would like the idea to be able to have the data-object in-band in the response. Please note that I am NOT pushing for in-band only. I am still trying to get systematics into the way to request data objects in different Jabber sub-protocols.

Yes in case of XHTML the author could simply put an HTTP URL. But this only solves the problem for XHTML. Still avatars can not be fetched via HTTP. Avatars over sipub is OK from client to client, but avatar galleries would work well with HTTP. So how do you specify the HTTP URL for an avatar? And I repeat: avatars are just the example. Soon we will design YAJP (yet another Jabber protocol), which retrieves data objects via sipub, in-band or OOB. There will be a YAJP-Wiki and peopel will discuss again the same issues as for avatars. 

So, there really should NOT be an avatar protocol. There should be a more general one. A more general protocol means that it should support different methods in a harmonized way. It will probably be just a wrapper for IBB, sipub, or XHTML-obj, and some disco. Maybe some have to be adapted, maybe not. But if there is an avatar protocol, then we will get YAJP soon after, which will be very similar. 

hw
--
Dr. Klaus H. Wolf
bluehands GmbH & Co.mmunication KG
http://www.bluehands.de/people/hw
+49 (0721) 16108 75
--
Jabber enabled virtual presence on the web: http://www.lluna.de/
Open Source Future History: http://www.galactic-developments.com/



> -----Original Message-----
> From: standards-jig-bounces at jabber.org
> [mailto:standards-jig-bounces at jabber.org]On Behalf Of Richard Dobson
> Sent: Thursday, July 01, 2004 7:55 PM
> To: Jabber protocol discussion list
> Subject: Re: [Standards-JIG] avatars
> 
> 
> > Maybe by generalizing the <obj/> of
> > http://www.jabber.org/wiki/index.php/XHTML%20Inband%20Images:
> 
> Just a couple of things as one of the co-creators of this protocol.
> 
> > Sipub:
> >  <obj xmlns='http://jabber.org/protocol/iobj#sipub' cid='id1'
> >       id='publish-0123' />
> 
> > In-band with base64:
> >  <obj xmlns='http://jabber.org/protocol/iobj#inband' cid='id1'
> >       mime-type='image/png'
> >       encoding='base64' >0F58G4c02a90F58G4c02a90F58G4c02a90F5</obj>
> 
> > In-band as plain:
> >  <obj xmlns='http://jabber.org/protocol/iobj#inband' cid='id1'
> >       mime-type='text/plain'
> >       encoding='plain' >THE DATA</obj>
> 
> > Oob:
> >  <obj xmlns='http://jabber.org/protocol/iobj#oob' cid='id1'
> >       src='http://www.server.org/theimage.jpg' />
> > -> server will return mime type.
> 
> This tag was designed to work in a similar way to the object 
> tag in XHTML so
> since the attribute for mime type in XHTML is type and not 
> mime-type I think
> we should stick with type.
> 
> Also I dont see the point in altering the protocol in this way for
> supporting avatars, it was designed with a specific purpose 
> in mind as is
> shown in the wiki, also one of the main design features that 
> you seem to
> have eliminated in your suggestion is its use of a file hash, 
> which means
> once you have the file you dont need to re-download it, even 
> if it comes
> from someone else, also inband should not be done as these 
> sorts of things
> as they should be pull rather than push, i.e. the receiving 
> user must have
> the option of rejecting it and certainly shouldnt need to be 
> sent it again
> if they already have a copy of that file (even if from 
> someone else). Also
> the use of Oob as you suggest is redundant since the user 
> would have just
> put the HTTP url in the XHTML message and not needed the inband object
> specifier in the first place. Also your use of sipub still 
> eliminates the
> file hash meaning even if you have the file in question 
> already when someone
> else tries to send you the image or whatever you still need 
> to redownload it
> again, when there should be absolutely no need to.
> 
> Richard
> 
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> https://jabberstudio.org/mailman/listinfo/standards-jig
> 



More information about the Standards mailing list