at the risk of repeating myself, this is what i was trying to get at earlier. i don't think that inventing "filesystem mime" for performance reasons makes sense.
what percentage of email even has attachments? never mind a having a strictly reversable function such that f*(f(email)) → email. in order to preserve the basic difference between multipart/alternative and multipart/mixed, one would need a metadata file containing that information. in some sort of new format. - erik Dave Eckhardt <[EMAIL PROTECTED]> writes | | > Given that the current mbox file format doesn't scale well to | > tens of thousands of emails, I'm not worried about the fact that | > the file system doesn't either. | | The standard hack (did MH ever pick this up?) is to split the | directory, e.g., message 32456 is stored in 32/456 or 3/2/456. | | The huge storage/locality win for separating out large attachments | if you have venti-like storage (or want to cache virus-scan results) | may well justify tearing the file apart on nextpart boundaries--my | only concern is that the process be 100% reversible by upas when you | ask. Heck, it could be as simple as "each message is 1 directory, | containing chunks stored one per file, named by integers, and the | original message is formed by cat'ing the chunks in numerical order". | That would let the storing agent decide whether the nextpart boundary | foo belongs in the same chunk as the bits or in its own micro-chunk. | | Dave Eckhardt | | P.S. At present upas does the >From thing, which isn't reversible.
