minich@d.cs.okstate.edu (Robert Minich) (10/06/90)
Pardon my arrogance, but why not support both uuencode AND binhex? I am not familiar with the method of enclosure, but surely it's not THAT hard. It's nice to have uuencode to talk to non-Mac people on the net (the vast majority) as well as the Rest Of Us (tm). For instance, say I wanted to mail a colleague a nice GIF from my Mac to his ???. Just send it as uuencode and he can do something with it even if ??? is a Mac since his software supports both flavors. So really... how hard _is_ it to support the uuencoded enclosures? -- |_ /| | Robert Minich | |\'o.O' | Oklahoma State University| A fanatic is one who sticks to |=(___)= | minich@d.cs.okstate.edu | his guns -- whether they are | U | - Ackphtth | loaded or not.
dorner@pequod.cso.uiuc.edu (Steve Dorner) (10/08/90)
In article <1990Oct6.074537.14443@d.cs.okstate.edu> minich@d.cs.okstate.edu (Robert Minich) writes: > > Pardon my arrogance Ok; you've always seemed like a nice guy otherwise. :-) >but why not support both uuencode AND binhex? First: until a few weeks ago, I had no idea that there was a need for this conversion. It is hard to support file formats you didn't even know existed, and even I have SOME lead time... >I am not familiar with the method of enclosure, There you hit on the second reason. I'm not familiar, either, and I can't decode files in unknown formats. Uuencode I can figure out, but until John Norstad said "AppleSingle", I had no idea how things were packed within the file. Both people who requested that Eudora handle this format were unable to tell me anything beyond "uuencode". There is only so far I will go to repair somebody else's mistakes. Tracking down file formats from my "competitors" is a bit too far, given the other things I have to do, and the budget on which I have to do them. Third: the BinHex intro line "\n(This file must be converted with BinHex...)" is awfully explicit. Uuencode says: "\nbegin 644 name of file". This is a royal pain in the rear end, since it's hardly inconceivable that such a line might show up in the body of a message, and have *NOTHING* to do with uuencode. The more "guessing" in my program, the less happy I am; guessing costs performance, space, and reliability. >Just send it as uuencode and he can do >something with it even if ??? is a Mac since his software supports both >flavors. So really... how hard _is_ it to support the uuencoded enclosures? And how hard is it for the other platform to decode BinHex? If the other platform is UNIX, the answer is, "not hard". I dunno about the benighted who use IBM-PC type thingies; maybe they have uudecode, but do they know AppleSingle? I suspect not. Can they write code to handle it? Probably, but then they could have ported UNIX xbin, too. I don't buy this one; if Eudora gets uuencode, it will be to communicate with Quickmail, not MS-DOS. Now that I know the magic word (AppleSingle), I will consider putting uuencode support in Eudora, though it won't be my top priority. (PS-Anybody know where AppleSingle is documented? Email would do fine...) -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
strauss@Aero.Org (Daryll Strauss) (10/09/90)
In article <1990Oct8.165609.24787@ux1.cso.uiuc.edu>, dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: |> |> There you hit on the second reason. I'm not familiar, either, and I can't |> decode files in unknown formats. Uuencode I can figure out, but until John |> Norstad said "AppleSingle", I had no idea how things were packed within |> the file. Both people who requested that Eudora handle this format |> were unable to tell me anything beyond "uuencode". |> |> There is only so far I will go to repair somebody else's mistakes. Tracking |> down file formats from my "competitors" is a bit too far, given the other |> things I have to do, and the budget on which I have to do them. |> |> Third: the BinHex intro line "\n(This file must be converted with BinHex...)" is awfully explicit. Uuencode says: "\nbegin 644 name of file". |> This is a royal pain in the rear end, since it's hardly inconceivable that |> such a line might show up in the body of a message, and have *NOTHING* to do |> with uuencode. The more "guessing" in my program, the less happy I am; |> guessing costs performance, space, and reliability. |> |> >Just send it as uuencode and he can do |> >something with it even if ??? is a Mac since his software supports both |> >flavors. So really... how hard _is_ it to support the uuencoded enclosures? |> |> And how hard is it for the other platform to decode BinHex? If the other |> platform is UNIX, the answer is, "not hard". I dunno about the benighted |> who use IBM-PC type thingies; maybe they have uudecode, but do they |> know AppleSingle? I suspect not. Can they write code to handle it? |> Probably, but then they could have ported UNIX xbin, too. I don't buy this |> one; if Eudora gets uuencode, it will be to communicate with Quickmail, |> not MS-DOS. |> |> Now that I know the magic word (AppleSingle), I will consider putting uuencode |> support in Eudora, though it won't be my top priority. |> |> (PS-Anybody know where AppleSingle is documented? Email would do fine...) |> -- |> Steve Dorner, U of Illinois Computing Services Office |> Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner That really isn't a fair description of the situation. We are using GatorMail-Q and every message with an enclosure includes this line in the header: Content-Type: x-uuencode-apple-single So, there is documentation as to what the format is for enclosed message. In fact, the Content-Type header is documented in RFC-1049 and RFC-1154 so it isn't like they made this up out of the blew. The rfc indicates that any atom on the right-hand-size of a Content-Type is a "private atom", so they just created their own atom to indicate the type of encoding used in the enclosure. The Gatorbox software includes some C code and manual page that converts between apple-double and apple-single format, so most folks with Gatorboxes should have that. I can't argue about what the "best" format for enclosing documents, but it seems that Cayman/StarNine did a reasonable job with their enclosure. - |Daryll ------------------------------------------------------------------------------- Daryll Strauss f The Aerospace Corp. strauss@aero.org n Mail Stop: M1-102 ...!uunet!aero.org!strauss o P.O. Box 92957 r Los Angeles, Ca. 90009 I don't work for Cayman/StarNine. This is FYI. d (213) 336-9358 -------------------------------------------------------------------------------