RE: Patch for alternate content handling

Good stuff, Jose!

Regarding your proposal for attachments: In our (v1.plus) archives, we have an ".attachments/" subdirectory, and then files go into .attachments/NNNN/ subdirectories, where NNNN is the serial number of the message. We don't bother changing the names provided by the sender. In practice (albeit on an intranet), this hasn't been an issue.

I prefer the additional subdir since it leaves the archive directory uncluttered. The only time you'll have to look at a bunch of NNNN/ subdirectories is if that's what you're after.

Cheers,
_____________ Hewlett-Packard Computer Peripherals Bristol Tom von Alten mailto:Tom_vonAlten_at_boi.hp.com

          This posting is for informational purposes only.
          It is not a statement of the Hewlett-Packard Co.

Jose Kahan writes:
...
> The parsing is OK, but the way that the attachment filenames are
> generated and stored (in the same dir where all the .html files go)
> is a bit hard to maintain. Also, if you'd like to regenerate
> a hypertext
> archive from the mbox, filenames may change and that will surely
> reak many existing links to the archives. One should avoid this
> whenever possible.
>
> What I'll do is create a subdir, using the msgnum, something like:
> att-msgnum/
> and store all the attachments there, using a fixed rule to create the
> attachment name, rather than the tmpnam function.
... Received on Wed 30 Jun 1999 10:11:19 PM GMT