On Mon, Oct 31, 2005 at 11:54:12AM +1100, Trejkaz wrote:
> > Trejkaz wrote:
> >>> So I assume PyMSNt does something incorrectly. (Eg. following the MIME
> >>> standard instead of detecting the filetype of an avatar properly).
> >>
> >> Whoa, that's the first time I've ever heard someone say that following a
> >> standard is being incorrect. ;-)
> >
> > Have you done much work involving Microsoft technologies? ;)
>
> Yes, but... I've noticed that Microsoft have been very careful not to
> claim that they're complying with any standards. And in any case,
> following standards would still be correct, if they ever decide to start.
> ;-)
Following standards is certainly a good thing(tm), people . . .
but:
Correct code / configuration should mean that you can interoperate and
are compatible with 99% (or another high percentage) of other users,
where-ever possible (with MSN and e-mail, not too hard I believe).
Geez, I'd love to *auto* sign every mail I send with PGP-MIME, but
Outlook Express users force me to think twice before signing.
<PGP details>
M$ Outlook (Express) blatantly *hides* PGP-MIME signed my message
bodies, even though MIME says unknown plain text elements should be
displayed automatically (inside MUA preferably).
So again in that case, I'd consider following the nice standards a
misconfiguration. I don't know if PGP inline is standard after all --
but I wouldn't consider it a nice standard anyway.
Other people might be more rigorous and force Outlook users to open
their PGP-MIME signed mails with Notepad . . . .
</PGP details>
I have no idea if PyMSNt needs the following suggestion, but since I
thought of it now I may as well write it down.
Implementation idea: the UNIX "file" utility can show the type of a file
without relying on either MIME headers or file extensions.
Example:
$ file ~/.face
PNG image data, 48 x 48, 8-bit/color RGBA, non-interlaced
$ file ~/.face.old
JPEG image data, JFIF standard 1.01
If desired, similar techniques might be possible in a more Pythonic way
(read: available on both Linux & Windows servers...); but I don't know
enough Python for that (yet..).
Please note that Jabber clients could/should also implement such a
technique... (preferably, to interoperate with broken clients)
--
Andreas [ http://unstable.nl | xmpp:[EMAIL PROTECTED] ]
[ callto:ils.seconix.com/[EMAIL PROTECTED] ]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://modevia.com/pipermail/py-transports/attachments/20051031/7f470dfb/attachment.pgp
From [EMAIL PROTECTED] Mon Oct 31 04:59:03 2005
From: [EMAIL PROTECTED] (Trejkaz)
Date: Mon Oct 31 05:01:26 2005
Subject: [py-transports] avatar: interoperability ideas
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
> Geez, I'd love to *auto* sign every mail I send with PGP-MIME, but
> Outlook Express users force me to think twice before signing.
I know what you mean. I had a recruiter once send me a mail saying that
one of my messages was blank, which was how I originally discovered this.
I had to tell them to use a different client to read it because I wasn't
so desperate that I would downgrade my own convenience for the benefit of
a mere recruiter. Some other times I don't think I could do the same. ;-/
> If desired, similar techniques might be possible in a more Pythonic way
> (read: available on both Linux & Windows servers...); but I don't know
> enough Python for that (yet..).
<snip>
I suspect the Python imaging library knows how to identify a binary stream
as the correct format already. I know for certain that ImageMagick is
smart enough to do it (which most imaging libraries seem to use
underneath) and Java's ImageIO is smart enough too.
But even if it can't, the patterns are fairly well known...
PNG: 0x89, 0x50, 0x4E, 0x47, 0x0D, 0x0A, 0x1A, 0x0A
GIF87a: 0x47, 0x49, 0x46, 0x38, 0x37, 0x61
GIF89a: 0x47, 0x49, 0x46, 0x38, 0x39, 0x61
JPEG: 0xFF, 0xD8, 0xFF
...and so on for any other formats which are possible. I know with the
place I work for, we ended up implementing this natively, and it wasn't
completely unbearable to do, just time consuming (of course, we identify
more filetypes than mere images... and indeed in some cases more filetypes
than the file command.)
That being said, we shouldn't just blindly allow someone to claim to have
one format and then actually have another. We need some way to nag back
at that user to fix their avatar, otherwise nobody will ever follow the
standards. :-)
TX
