temas at box5.net
Fri Jul 2 15:38:14 UTC 2004
On Jul 2, 2004, at 6:49 AM, Richard Dobson wrote:
>> I see, that I did omit the hashes. Hashes are important and we use
>> exactly for what you say. My client fetches avatars from many users.
> is done
>> only if the hash does not match. (These <obj/>s were just example
>> what I
>> by harmonization. I did not propose the next protocol. They were for
>> complete nor correct)
> Ok, good, yup the filehashes must stay.
>> Also there are obviously 2 notions of in-band here. I agree that data
>> should not be in-band when something (XHTML) is pushed. In this case
>> 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
> 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
> trying to
>> get systematics into the way to request data objects in different
> If you want to receive the object inband then you just follow it along
> at the file transfer stage just specify that you want it using IBB,
> IMO it
> should be kept nice and layered like it is now re-using existing
>> Yes in case of XHTML the author could simply put an HTTP URL. But this
>> solves the problem for XHTML. Still avatars can not be fetched via
>> over sipub is OK from client to client, but avatar galleries would
> well with HTTP.
>> So how do you specify the HTTP URL for an avatar? And I repeat:
> are just
>> the example. Soon we will design YAJP (yet another Jabber protocol),
>> 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.
> Then maybe we need to extend obj slightly for more general use for HTTP
> URL's as follows
> <obj xmlns='http://jabber.org/protocol/iobj'
>> So, there really should NOT be an avatar protocol. There should be a
> 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,
> 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.
> If you read my previous email you will see that there is no need to
> invent a
> new generic wrapper as IMO our XHTML obj spec already provides a pretty
> generic framework, it is fine as a wrapper for file transfer (no need
> to be
> a wrapper for IBB as by using filetransfer it will automatically pick
> appropriate transfer method be that OOB or IBB).
I've been watching this off and on for the past few days, and I'm not
really understanding where the discussion is going, primarily in
relation to avatars. What I took back from my last RFC on the avatar
wiki was that we needed to figure out OOB, and I would prefer it to be
in SI. So then the only question is do we need a generic way to say "I
know where you can get a chunk of data" in a generic way? I'm not sure
how much that actually gains since, using avatars as an example, we
have an extremely simple wrapper for sipub to just give it a bit more
context. Sipub is doing the most of the work and is easy to have as a
common impl. So I guess I need clarification on how this is not
already mostly generic? It would be nice if some others would comment
in here too, seems to be a 2 person conversation at this point.
More information about the Standards