Hi, On Dec 6, 2005, at 6:09 PM, Norman Rasmussen wrote:
> The whole point of using the hash is it's a global fingerprint of the > file. If one user used sha1 and another user used xyz, then they > might generate the same hash for seperate files. What's the client > supposed to do then? Store one image per roster item? No, the only thing you can get from the hash is the fact the I sent you an hash of X and then I sent you an hash of Y. That means that my image as changed. If *all* the client behave and implement correctly the protocol, you can then assume that the hash of the binary representation of the image is the hash sent in the presence stanza. As we can see from this thread, some clients don't behave correctly. The question of local storage is totally unrelated. By all means hash each image that you get and store them per hash, so that images with the same hash are stored only once. My only point in the whole thread is this: if you use the hash only as a signal that the avatar has changed, you'll have a better client in the sense that it will work no matter what other clients/servers do. > What happens if a bunch of users use the same image, in different > clients. The sha1 hashes of all the images are identical, but each > user's client sends a different key because they calcuate it > differently. This means you download the same image more than once > which is bad. Yes, it is bad. And yes, it's a drawback of my way of doing things. In the end, we decided to do it anyway because the cost of angry customers when the avatar is not updated correctly was greater then the bandwidth cost. But it was on our case. We will probably do it like you say depending on the capabilites of each client, marking good clients. Please note that I agree with you and that SAPO client will send the SHA1 hash of the binary image. I'm just saying that this fallback I'm describing will catch clients that mis-behave. > The simple and easy fix is that all new implementions use the raw > image data. Correct, and the clarifications on the XMPP std list point to that, without the need of clarification (although I believe that we should clarify it anyway). > PyMSNt's changing of the image format is so that the legacy network > clients can display the data correctly. Although I have seen an MSN > contact with an animated gif, obviously PyMSNt breaks that image :-(. > PyMSNt probably shouldn't change the image type, it should make the > client do that. (keeps code simple too) Maybe. I admit that I don't know exactly what I feel about this one. It all depends on what's easier to do from the MSN side... Best regards, > On 12/6/05, Pedro Melo <[EMAIL PROTECTED]> wrote: >> Hello, >> >> On Dec 5, 2005, at 6:15 PM, Norman Rasmussen wrote: >> >>> and when the hash changes, and you get the vcard, you have to >>> 'assume' >>> that the presence hash matches the hash of the image data, because >>> other users _might_ send the same presence. >> >> And this is bad why? >> >>> FYI: JEP-0153 is a Historical JEP, i.e. it attempts to provide >>> documentation of a protocol that is already in use within the >>> Jabber/XMPP community. i.e. When in doubt refer to clients that >>> implemeted the protocol before the JEP was written. >> >> Correct, yet what I'm suggesting will make your client work no matter >> what other clients do. >> >> And is still valid. >> >>> in this case a _tiny_ change to gajim, or we change all of: >>> JEP-0153/Psi/Kopete/iChat/PyMSNt/etc/etc. >> >> I all for clarification. We should SHA1 the binary representation of >> the image always. But I still think that even then you should use the >> hash blindly. >> >> For ex: pyMSNt changes the image format from whatever you send to a >> PNG. If some other server does the same, you might get it wrong. >> >> Best regards, >> >> >>> On 12/5/05, Pedro Melo <[EMAIL PROTECTED]> wrote: >>>> But is included in the presence. >>>> >>>> If the hash is absent from the presence, you should not use the >>>> photo >>>> as avatar, per jep 0153 spec. At least that's my reading of items 1 >>>> and 2 of section 4.1. >>>> >>>> Best regards, >>>> >>>> On Dec 5, 2005, at 5:32 PM, Norman Rasmussen wrote: >>>> >>>>> Except that the hash is not included in the vCard. >>>>> >>>>> On 12/5/05, Pedro Melo <[EMAIL PROTECTED]> wrote: >>>>>> Hi >>>>>> >>>>>> Another solution for this, would be to treat the hash as an >>>>>> opaque >>>>>> value. >>>>>> >>>>>> That means that the client should store the image and the hash >>>>>> that >>>>>> was used. >>>>>> >>>>>> This way, it doesn't matter how the hash was generated. >>>>>> >>>>>> Best regards, >>>>>> >>>>>> On Dec 5, 2005, at 2:59 PM, Norman Rasmussen wrote: >>>>>> >>>>>>> On 12/5/05, Jeff Licquia <[EMAIL PROTECTED]> wrote: >>>>>>>> >>>>>>>> Iris (Psi, Kopete) doesn't seem to use the hash at all. I was >>>>>>>> unable to >>>>>>>> find other examples of avatar handling in client source. >>>>>>> >>>>>>> The Pedrito build of Psi _does_ cache images, you would have to >>>>>>> check >>>>>>> the patches applied there to make sure. >>>>>>> >>>>>>>> The JEP should probably be clearer on this point. >>>>>>> >>>>>>> I have a bone to pick with 'base64' encoding. Some >>>>>>> implementations >>>>>>> create a newline after every 64 characters, others don't. >>>>>>> Across >>>>>>> different platforms, these newlines will differ: \n (*nix) vs >>>>>>> \r\n >>>>>>> (win32) vs \r (mac). As an absolute minimum _if_ the hash is >>>>>>> computed >>>>>>> using the base64 encoded data, the newlines must be removed. >>>>>>> >>>>>>> All this confusion is removed if the hash is computed on the raw >>>>>>> image >>>>>>> data. Also it's far simpler to compute the hash on the raw data >>>>>>> using >>>>>>> _any_ tool. (i.e. openssl, sha1sum, etc) >>>>>>> >>>>>>> -- >>>>>>> - Norman Rasmussen >>>>>>> - Email: [EMAIL PROTECTED] >>>>>>> - Home page: http://norman.rasmussen.co.za/ >>>>>>> _______________________________________________ >>>>>>> py-transports mailing list >>>>>>> py-transports@blathersource.org >>>>>>> http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports >>>>>> >>>>>> -- >>>>>> HIId: Pedro Melo >>>>>> SMTP: [EMAIL PROTECTED] >>>>>> XMPP: [EMAIL PROTECTED] >>>>>> >>>>>> _______________________________________________ >>>>>> py-transports mailing list >>>>>> py-transports@blathersource.org >>>>>> http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports >>>>>> >>>>> >>>>> >>>>> -- >>>>> - Norman Rasmussen >>>>> - Email: [EMAIL PROTECTED] >>>>> - Home page: http://norman.rasmussen.co.za/ >>>>> _______________________________________________ >>>>> py-transports mailing list >>>>> py-transports@blathersource.org >>>>> http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports >>>> >>>> -- >>>> HIId: Pedro Melo >>>> SMTP: [EMAIL PROTECTED] >>>> XMPP: [EMAIL PROTECTED] >>>> >>>> _______________________________________________ >>>> py-transports mailing list >>>> py-transports@blathersource.org >>>> http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports >>>> >>> >>> >>> -- >>> - Norman Rasmussen >>> - Email: [EMAIL PROTECTED] >>> - Home page: http://norman.rasmussen.co.za/ >>> _______________________________________________ >>> py-transports mailing list >>> py-transports@blathersource.org >>> http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports >> >> -- >> HIId: Pedro Melo >> SMTP: [EMAIL PROTECTED] >> XMPP: [EMAIL PROTECTED] >> >> _______________________________________________ >> py-transports mailing list >> py-transports@blathersource.org >> http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports >> > > > -- > - Norman Rasmussen > - Email: [EMAIL PROTECTED] > - Home page: http://norman.rasmussen.co.za/ > _______________________________________________ > py-transports mailing list > py-transports@blathersource.org > http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports -- HIId: Pedro Melo SMTP: [EMAIL PROTECTED] XMPP: [EMAIL PROTECTED]
