[VM] MIME encoding/decoding

[Uday Reddy]

VM has traditionally shipped with C programs for MIME encoding/decoding.
Rob F created an entire Unix-like infrastructure (Make files, configure,
autoconf etc.) pretty much to handle just these. If we get rid of these C
programs, VM can be shipped just like any other emacs library.

Both GNU Emacs and XEmacs now have built-in encoding/decoding functionality
for base64. So, we can use them. For the Quoted Printable format,
emacs-lisp seems to be fast enough. Gnus has been using it for ages and
everybody seems happy with that.

So, I am thinking of getting rid of the C programs for MIME. Does anybody
see any problem with that?

Cheers,
Uday

(Coming back after a long hibernation)

[Lewis Perin]

Post by Uday Reddy
VM has traditionally shipped with C programs for MIME encoding/decoding.
Rob F created an entire Unix-like infrastructure (Make files, configure,
autoconf etc.) pretty much to handle just these. If we get rid of these C
programs, VM can be shipped just like any other emacs library.
Both GNU Emacs and XEmacs now have built-in encoding/decoding functionality
for base64. So, we can use them. For the Quoted Printable format,
emacs-lisp seems to be fast enough. Gnus has been using it for ages and
everybody seems happy with that.
So, I am thinking of getting rid of the C programs for MIME. Does anybody
see any problem with that?

Sounds good to me. Thanks!

/Lew
---
Lew Perin / ***@acm.org
http://babelcarp.org

[Manuel Hermenegildo]

Sounds good to me too! --Manuel

[John Hein]

Post by Uday Reddy
VM has traditionally shipped with C programs for MIME encoding/decoding.
Rob F created an entire Unix-like infrastructure (Make files, configure,
autoconf etc.) pretty much to handle just these. If we get rid of these C
programs, VM can be shipped just like any other emacs library.
Both GNU Emacs and XEmacs now have built-in encoding/decoding functionality
for base64. So, we can use them. For the Quoted Printable format,
emacs-lisp seems to be fast enough. Gnus has been using it for ages and
everybody seems happy with that.
So, I am thinking of getting rid of the C programs for MIME. Does anybody
see any problem with that?
Cheers,
Uday
(Coming back after a long hibernation)

We should check the performance of builtin decoding - particularly
with larger messages on slower machines. That said, most of the unix
flavors & cygwin out there now have one or more command line tools to
en/decode base64 (less prevalent are qp tools) which can take the
place of the vm versions:

mmencode (both)
mimencode (both)

base64
b64en/decode
qprint

not to mention perl & python one liners.

[Uday Reddy]

Post by John Hein
We should check the performance of builtin decoding - particularly
with larger messages on slower machines. That said, most of the unix
flavors & cygwin out there now have one or more command line tools to
en/decode base64 (less prevalent are qp tools) which can take the

As I said, base64 is now a non-issue because Emacsen have built-in functions
for it.

For Quoted Pritable, you can check performance of the elisp code by setting
qp-decoder-program and qp-encoder-program to nil.

Cheers,
Uday

[Volker A. Brandt]

Dear Uday!


Thank you for keeping VM alive.

Post by Uday Reddy
VM has traditionally shipped with C programs for MIME encoding/decoding.

[...]

Post by Uday Reddy
So, I am thinking of getting rid of the C programs for MIME. Does anybody
see any problem with that?

Maybe they could be bundled in a separate distribution file?
And there could be some hooks in VM that would use the binaries
if found in $PATH, and fall back to Lisp code if they aren't found?


Best regards -- Volker

[Reinhard Kotucha]

Post by Volker A. Brandt
And there could be some hooks in VM that would use the binaries
if found in $PATH, and fall back to Lisp code if they aren't found?

This is by far the best solution, if not the only reasonable one.
It's inexpensive and Raspberry Pi users will be grateful.

Regards,
Reinhard

[Mark Diekhans]

Hi Uday,

Suggest keeping these in the source tree if anyone really needs
them, but not make part of a standard package.

Mark

Post by Uday Reddy
VM has traditionally shipped with C programs for MIME encoding/decoding.
Rob F created an entire Unix-like infrastructure (Make files, configure,
autoconf etc.) pretty much to handle just these. If we get rid of these C
programs, VM can be shipped just like any other emacs library.
Both GNU Emacs and XEmacs now have built-in encoding/decoding functionality
for base64. So, we can use them. For the Quoted Printable format,
emacs-lisp seems to be fast enough. Gnus has been using it for ages and
everybody seems happy with that.
So, I am thinking of getting rid of the C programs for MIME. Does anybody
see any problem with that?
Cheers,
Uday
(Coming back after a long hibernation)

[Ulrich Mueller]

Post by Uday Reddy
VM has traditionally shipped with C programs for MIME encoding/decoding.
Rob F created an entire Unix-like infrastructure (Make files, configure,
autoconf etc.) pretty much to handle just these. If we get rid of these C
programs, VM can be shipped just like any other emacs library.
Both GNU Emacs and XEmacs now have built-in encoding/decoding functionality
for base64. So, we can use them. For the Quoted Printable format,
emacs-lisp seems to be fast enough. Gnus has been using it for ages and
everybody seems happy with that.

These C programs were first shipped with in VM 6.76 which was released
in September 2000. This is somewhat surprising, because at that time
Emacs (version 20.4 then) already included the base64-decode-region
etc. functions.

Post by Uday Reddy
So, I am thinking of getting rid of the C programs for MIME. Does anybody
see any problem with that?

It may well be that they have outlived their purpose. But before
removing them, please make sure that it doesn't have any negative
impact on performance.

Ulrich

[Patrick P Murphy]

Post by Ulrich Mueller

Post by Uday Reddy
VM has traditionally shipped with C programs for MIME
encoding/decoding. ...

These C programs were first shipped with in VM 6.76 which was released
in September 2000. This is somewhat surprising, because at that time
Emacs (version 20.4 then) already included the base64-decode-region
etc. functions.

No, it's not surprising. Typical resources at the time for a
near top-of-the-line PC would have been:

550 MHz processor (just one, no cores)
64 Megabytes (not Gigabytes) of RAM if you were very lucky
ATA-2 hard drive, maybe 10 or 20 Gigabytes.

Performance was a real issue, and in a speed battle between emacs lisp
and a compiled C program, the latter usually won by at least one order
of magnitude, maybe two.

Times change. Computers are faster. For most modest size attachments,
people don't notice the difference anymore. People who get massive
attachments in the mail from others still do. I work in a "big data"
environment so I see this sort of thing a lot, even though most of my
co-workers know that SMTP is a rotten way to send large files around ;-}

I'm neutral on whether the programs are left as part of the VM tree or
not, as long as (a) the same functionality is available elsewhere [it
is, modulo cmd line arguments]; and (b) hooks are left in place to
allow us to override the built-in versions.

- Pat

[Ulrich Mueller]

Post by Patrick P Murphy

Post by Ulrich Mueller
These C programs were first shipped with in VM 6.76 which was released
in September 2000. This is somewhat surprising, because at that time
Emacs (version 20.4 then) already included the base64-decode-region
etc. functions.

No, it's not surprising. Typical resources at the time for a
550 MHz processor (just one, no cores)
64 Megabytes (not Gigabytes) of RAM if you were very lucky
ATA-2 hard drive, maybe 10 or 20 Gigabytes.
Performance was a real issue, and in a speed battle between emacs lisp
and a compiled C program, the latter usually won by at least one order
of magnitude, maybe two.

The base64-* functions always were internal Emacs functions, i.e.
implemented in C. Therefore I doubt that one could improve performance
by calling an external program, which has additional overhead for
spawning a new process.

Adding these programs to VM would still have made sense in the late
1990s, but no longer in 2000 when Emacs 20.4 had the built-in C
functions.

Ulrich