From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <8ccc8ba40806120703k5849a853t869a3eefe2ba309f@mail.gmail.com> Date: Thu, 12 Jun 2008 16:03:22 +0200 From: "Francisco J Ballesteros" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net> In-Reply-To: <6dbea45b0e4c8e2941b0bf5bcb371eb4@quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6dbea45b0e4c8e2941b0bf5bcb371eb4@quanstro.net> Subject: Re: [9fans] store 9p session-only values using lib9p Topicbox-Message-UUID: bd670216-ead3-11e9-9d60-3106f5b1d025 This mail with a reply inlined would be msgdir/ msgdir/text msgdir/raw If, the reply was inlined. Anyone wanting to use the original can go use raw. But the nice thing is that you can edit text, copy attachments in/out, remove them, etc. etc. Compatibility in my case is achieved by leaving upas et al. as they are; I convert just my mail once it entered the system. On Thu, Jun 12, 2008 at 2:25 PM, erik quanstrom wrote: >> 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 > > >