On Jan 23, 2007, at 1:13 PM, Rich Siegel wrote:
If you're still using Mac OS 9 and working heavily with documents that require resource forks and file metadata in order to work correctly, then naturally you'll want to take care to preserve that info when mailing them -- but I think AppleDouble isn't the answer; see below.
Ok, you are right, I should have qualified my statement... my "best" is specific to the use of Emailer, in which case, yes, it is expected to be used under OS 9 or regularly involve OS 9 or earlier (ie: things that might care about a resource fork).
I assumed that was a given in an Emailer list, but I shouldn't have made that assumption, and certainly the way I wrote it, it does seem to be a "without exception" type of statement.
Remember, under OS 9, file type and creator codes are stored in the resource fork, so any time that is stripped off, the OS has to decide what should be opening the file based on other info, such as .3 extensions... but Mac users (prior to OS X) don't generally assign those extensions to a file name. So that means the attachment comes in as an unknown orphan, meaning no "double click" to open the file easily.
If I sent a file called "account info" to someone that was a screen shot of my Emailer account setup, and I used a non resource fork friendly attachment type, that person will get the file and may have no idea what to do with it or how to open it. Is it a text file? Is it a screen shot? A PDF?, what?!? (I use this example, because it has been done to me MANY MANY MANY times in support of Emailer).
If AppleDouble was used (or any resource fork friendly encoding type), then the type/creator codes would still be there, and the file would be assigned to the correct application, allowing it to be easily opened. BinHex would work just as well, but see below on why I don't recommend defaulting to it.
With respect, I must differ. If you are sending a Mac file to a recipient on a Mac, it's impossible to go wrong using BinHex. If you are sending a cross-platform file (text, Word, Excel, RTF, most image formats, maybe even Photoshop documents) to a recipient on any platform, Base64 should do just fine.
The problem with this is, now the sender has to think. If the sender was worried about thinking, then this whole thread doesn't apply. The point was to come up with a single choice that could be used 99% of the time without worrying about anything. BinHex doesn't work at all on almost all non Mac systems, they just don't support it, so the attachment comes in as useless garbage. Sure, the user could open it by saving that garbage as a text file and running it thru a program that can decode BinHex, but that is even more effort (and involves even more thinking, and I'm pretty sure everyone on this list knows my feelings regarding Windows users being able to think)
I'd rather use AppleDouble and not have to think about "do I need resource fork support on this attachment or not" and then change my encoding method as needed. AppleDouble takes the guess work out of it. As Ron Popeil likes to say "Set it and forget it". :-)
So if we look at the three possible choices for Emailer, BinHex, Base64, and AppleDouble (we will ignore AppleSingle and UUEncode as both are pointless pretty much everywhere), what do we come up with. BinHex, always correct for Mac, useless and likely problem inducing for everyone else. Base64, correct for everyone else, usable for some Mac, but problem inducing for other Mac situations. AppleDouble, always correct for Mac, usually usable for everyone else (really only unusable for certain "idiot" non Mac users that can't be taught to ignore the unneeded 2nd attachment).
That really makes it look like AppleDouble is still the best option, as it seems that it would make it useable for the greatest number of people with the least thought and headaches involved.
The _one_ time AppleDouble is useful is when the file needs to pass through a non-Mac recipient to get to a Mac, and by this I mean that the recipient of the email is reading the message and extracting the enclosure on a PC and will eventually get the file onto a Mac. But that's a pretty specialized set of circumstances that rarely occurs in nature.
Actually, it is starting to happen more and more with server side anti-virus checks. There are growing instances of AV scanners flagging as a virus anything it can't scan, and too many of them only support Base64 as an encoding type. So a BinHex file would be flagged incorrectly as a virus simply because it couldn't decode it to check it. AppleDouble again avoids this as it will just see it as two Base64 attachments, scan them both, and send the email thru.
Regardless, like you alluded to, the whole issue is rapidly becoming moot as OS X doesn't use resource forks any more rendering the whole need for resource fork friendly encoding irrelevant. As more and more people move on, there will be less and less of a need to do anything other than Base64.
But on a list specific to older email software, given the situations that the general Emailer user is going to run into, and given the encoding types Emailer supports... I stand by my statement... AppleDouble is the best choice (although I amend that to "best for Emailer users" rather than my more general "best for Mac").
Think of it this way... this whole thread started because someone was trying to send an email attachment that needed the resource fork, and one possible reason it didn't arrive was they may have sent it using Base64... so the thread itself kind of negates the possibility that Base64 would be superior to AppleDouble for the purposes of this list.
:-p -chris <www.mythtech.net> ___________________________________________________________________________ To unsubscribe send a mail message with a SUBJECT line of "unsubscribe" to <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]>
