Re: Admin: a suggestion on the script corruption problem.
Re: Admin: a suggestion on the script corruption problem.
- Subject: Re: Admin: a suggestion on the script corruption problem.
- From: Joshua Juran <email@hidden>
- Date: Fri, 16 Feb 2001 14:25:21 -0500
At 9:56 AM -0800 2001-02-16, Chuq Von Rospach wrote:
>
Brad's suggestion was to create a tool that would take an AppleScript and
>
convert it into a form that isn't corrupted by the list server. That script
>
could then be posted safely, and that tool (or a mirror one) could then be
>
used to decode it on the other side to be used.
>
>
Since the scripts are already mostly readable (the problem are the
>
macOS-specific characters not part of the standard ascii character set),
>
this wouldn't impact the readability of posted code significantly, either.
Okay, you're talking about tweaking the unreadable characters into
something that survives the gateway without munging the rest of the script,
so general encoding tools like BinHex are right out.
>
If the users of these lists agree with me and someone's willing to put the
>
tools together, I'll be more than happy to host them on the list site for
>
download, and update the documentation to describe them and how to use them
>
and support their use on the list in an official way. I don't have the
>
resources to write these tools myself right now (or I would), but it seems
>
to me they'd be quick, straightforward, and easy to use.
I can do this; here's my proposal:
The tool consists of two droplets -- 'real' applications, each less than
125K in size, written in C++ (source included). Any text file dropped on
the encoder produces an output file of the same file type with a unique
extension. The sender opens this file and pastes the script into the email
editor.
The recipient copies the script and pastes it into a file, which is then
dropped on the decoder, which produces the original text file.
The encoding algorithm assumes that control characters (code points <
\0x20) are unimportant. Tabs in quoted strings could be corrupted in
transit (unless this is a problem, in which case I'll revise it). The
decoder will deal properly with the extra newlines the received encoding
may have. The encoding carries a version number (of the encoding
algorithm) just in case.
This solution requires a name and a file extension. Suggestions are welcome.
That's the general proposal. I'm still considering the specifics (such as
how to escape 8-bit characters in a readable way).
With admin approval I'll begin working on it. I anticipate a few hours to
complete the design and a day to implement it.
Josh
--
Joshua Juran Metamage Software Creations
=) Tools for Wizards
email@hidden
<
http://www.metamage.com/> * Creation at the highest state of the art *