Re: [9fans] store 9p session-only values using lib9p

[erik quanstrom <quanstro@quanstro.net>]

> Funny, I've done the same in a different way.
> see mail2fs in contrib/nemo.
> Also, I have some proposal, skip to the end of the mail and let me know
> what you think :)
>
> In any case, I'd love to see/try your version of upas/fs et al.

/n/sources/contrib/quanstro/src/nupas.  cavet emptor.

nupas/fs is fully compatable with upas/*.

i have been using the mdir format for about 18 months.  but i have
just recently added the bits to reduce memory footprint.

i'm currently spending quite a bit of time on this so details may change.

i would appreciate any feedback.

> Instead of adapting upas/fs, I use a mail2fs program that uses
> upas to convert mail into an "unpacked" form. Each mail is a directory.
> A "text" file contains the message text right as you would see it in a mail
> reader (including relative paths for attachments). Each attach is decoded
> and kept in the mail's directory ready to be copied, printed, etc.; if possible,
> using the same file name reported by the attachment.

it's hard denying that this is some allure to this idea and i definately
considered it.  however, we get quite a bit of three-part email containing
the mime parent a 150 byte message and the 400 (with headers) byte
replyed-to message.  depending on the details of your format, this
could require 3 directories + 3 files or 6 blocks of storage for a
smaller-than 1 block message.  (assuming 8kb blocks.)  it also could
result in quite a bit more seeking when scanning a number of messages.

in addition, this format is not compatable with any of the existing
tools.  in mdir format, each file looks like a mailbox of exactly one
message.  in addition, in mdir format each message is self-contained.
i can just cp it.

finally, a number of email security standards (so-called spf2.0 and
s/mime) require the original email.  it's not clear to me that one can
reconstruct an original mime message from processed parts without
leaving some breadcrumbs behind.  there's no requirement not to
base64-encode us-ascii, for example.

- erik