Mailing List Archive

> As usual, the development version ( 1.3-dev ) is available for
>[...]
> If anyone has any outstanding issues / queries / dud-mailpacks, let me know :-)


Hi Paul,

Is that fix (suggested earlier) for naming output files
going to be considered?

As a reminder: it's about consolidating the

textfile1 -> textfile0

slip, which currently (v1.2.17.0) requires heuristic
logic in the caller program to properly distinguish
between mail formats (e.g. multipart or plain) in
order to find the default message text.

Now, that textfile0 is the "This is a MIME message."
text for MIME and the actual text is in textfile1,
but that is textfile0 for non-MIME, the application
is required to know something that Ripmime knows much
better, but won't tell... ;)

A nice and transparent way of handling this is to
add "textfile0" as a "pseudo part" for non-multipart
mails, with a content like: "This is *not* a multipart
message". And put the actual message to textfile1,
as is with MIME.

Thus aplications would gain twofold:

- not only gone is the fiddling with figuring out
whether we need textfile1 or textfile0, because
we can *know* we never actually need textfile0
any more,

- but Ripmime also explicitly *tells* us if the mail
was not multipart.


How come nobody else has bumped into / showed interest
in this problem, only me? :) What am I missing? Please
let me know if yes, or please, add this simple enhancement.

Thanks very much!
Sab

Or, alternatively (which is also better in terms
of efficiency), simply don't generate textfile0
for plain single-part messages, so applications can
check the mail format by just access("textfile0")
(or something like that).

Sab

> As a reminder: it's about consolidating the
>
> textfile1 -> textfile0
>
> slip, which currently (v1.2.17.0) requires heuristic
> logic in the caller program to properly distinguish
> between mail formats (e.g. multipart or plain) in
> order to find the default message text.
>
> Now, that textfile0 is the "This is a MIME message."
> text for MIME and the actual text is in textfile1,
> but that is textfile0 for non-MIME, the application
> is required to know something that Ripmime knows much
> better, but won't tell... ;)
>
> A nice and transparent way of handling this is to
> add "textfile0" as a "pseudo part" for non-multipart
> mails, with a content like: "This is *not* a multipart
> message". And put the actual message to textfile1,
> as is with MIME.
>
> Thus aplications would gain twofold:
>
> - not only gone is the fiddling with figuring out
> whether we need textfile1 or textfile0, because
> we can *know* we never actually need textfile0
> any more,
>
> - but Ripmime also explicitly *tells* us if the mail
> was not multipart.

> As usual, the development version ( 1.3-dev ) is available for download at:
>
> http://www.pldaniels.com/ripmime/ripmime-1.3-dev.tar.gz

Sorry, the package does not seem to be there.

Cheers,
Sab