On Mon, 12 Mar 2001 22:49:37 PST, "James P. Salsman" said:
It's *conceivable* that your MUA reads directly from your system's
equivalent of /dev/microphone, base64's and writes directly to
the SMTP datastream outbound
Yes, that is what two of my MUAs do on certain platforms, and I think
that is also exactly what Qualcomm's Eudora does on multiple platforms.
Ouch. What happens if you decide that you want to *cancel* what you've
recorded? When I say *directly*, that's what I mean. When the 150th
byte of audio is input from the microphone, the SMTP MAIL FROM and RCTP
TO have already been sent, the RFC822 headers have been sent, the MIME
headers for this recording have already been sent - makes it difficult
to cancel at THAT point.
A simple thought experiment shows that Eudora does *NOT* do this. Proof -
after you finish recording, you *still* have to hit 'send'. Ergo, during
the time between 'finish' and 'send', that audio is stored someplace.
Certainly "Pocket Outlook" for WinCE also does it, bun until Microsoft
gets their act together regarding address book access and scriptable
message transmission, I'm not going near any Outlook family products.
Whether the buffer is in RAM or on the filesystem is incidental.
makes the attachment of multiple bodyparts "interesting"
The "inline" vs. "attachment" are still there to indicate whether the
part is intended to be presented or stored on arrival.
No.. What I *meant* was that unless you spool the audio into a temporary
file, as noted above, *creating* the e-mail with multiple attachments
is interesting.
That kind of thing, and the other scenarios you asked about, are
really more of what the filename or internal description fields of
audio file formats are for.
Right. And your proposal adds more value how?
you might make a .forward script to send all your inline audio sent
from microphone devices to your wireles PDA or cellphone or voicemail,
while ignoring inline audio from other devices. What's the worst
Actually, that's probably a bad criterion - I've had people ramble into
my voicemail until it fills up, and I don't want THAT being beamed to my
cellphone, while ignoring a short but important 10-second audio clip
just because it happened to have existed as a disk file at one time.
And what do you propose to do about the distinction between an MUA that
supports inline recording (and thus tags it "microphone") and the *SAME
USER* with the *SAME INTENT* who's message gets tagged with "disk file"
merely because the MUA he has installed on *this* machine doesn't support
inline recording, so he was forced to attach an audio part he recorded to
disk via an external program 15 seconds before? I send it with Eudora,
you'll listen to it, I send it with Exmh plus a config hack, you'll listen
to it, but I send it with Exmh without config hacks, you'll not listen because
it wasn't recorded inline? What's the logic here?
In addition, there's another issue here - if you send me an attachment
flagged as "microphone", what is the proper handling if I forward the
message? When I forward it, it's not microphone, it's a disk file.
And it's quite possible that the headers can't be modified because they're
covered by a PGP or S/MIME signature.
--
Valdis Kletnieks
Operating Systems Analyst
Virginia Tech