Re: [Nmh-workers] nmh in near, medium, and far-term

[Mike O'Dell]

We are getting dangerously close to an observation i've made
a few times recently, which is that "We've discovered Metadata!"
moreover, the "metadata" about a "file" is now as important as
the "data". We've poked and futzed with where to store metadata
for files, though I think "hide" is a better term, and have converged
(painfully) on storing general (key,value) tupes. The obvious head-slap
is that the "data" is just the value in one more tuple with a well-known
key like "filecontents". So there is no longer any data, only metadata!
so what was a "file" is now a "directory" or a "map" or a "hash" depending
on your first or favorite programming language.

i note ruefully that MacOS<10 files had a "data fork" for the bits
we know and love and a "resource fork" (which stored the key-value pairs)

what we really need is Plan 9 user filesystems so we could just "mount"
an MH-friendly "view" on top of a store more suited to the moderne world.

unfortunately, we don't got that yet.  however, note that the Kthings
and the Gthings desktops all go through libraries that allow the apps
to take URLs where apps would previously demand a filename.
maybe there's a way to reskin this skinless directory tree?

i will mention the old, ugly, disgusting, but damn powerful hack which
has saved the communal bacon more than a few times before:

    replace libc

or rather, intercept read(), write(), open(), close(), creat(), 
unlink(), etc...

This saved Netnews, UUCP, Sendmail, and UUNET's original accounting
system written in AWK, some more than once.

I just realized that with FUZE i guess we could go to the extreme of
a view filesystem if we felt compelled.

It's ironically amusing that one of the oldest non-original UNIX apps I 
still use day-in
and day-out is pushing this issue hard. Abstract semantics vs 
implementation semantics:
who wins? who should win?  As John Day says in his great book on network 
architecture,
"The problem with *reductio ad absurdum* is knowing when to stop!"

and on that bombshell, we have to end.  GOODNIGHT!

(cue ending theme)

    -mo




On 12/9/11 7:43 PM, Ralph Corderoy wrote:
> Hi,
>
> Oliver Kiddle wrote:
> > If you're going to do that, you might aswell name the files using an
> > SHA hash.
> Thoughts I've had over the years...  MH was handy because it integrated
> with the Unix command line and filesystem;  I still awk, etc.,
> ~/mail/inbox/* on occasion when nmh's commands don't suffice.  That's
> good;  I don't think nmh should grow every bell and whistle.
>
> MIME breaks this.  If all textual parts were stored in UTF-8 on disk
> things would improve once again.  Perhaps even a mail/inbox/42 for a
> UTF-8 summary of the email, headers and the body laid out as text where
> possible, and a mail/inbox/42/... with the headers and each part as a
> separate file, including sub-directories where needed, e.g.
> ~/mail/inbox/42/foo.png exists.  Plan 9 had something along these lines.
> http://plan9.bell-labs.com/magic/man2html/4/upasfs
>
> The other thing would be a single name for the email with links
> implementing folders/tags.  That backups think a lot has changed when a
> folder is packed is a flaw.  Possibly in the backup software, I'll
> admit.
>
> I don't see these fitting easily into nmh but thought I'd throw them out
> there whilst there's list activity.  :-)
>
> Cheers, Ralph.
>
> _______________________________________________
> Nmh-workers mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/nmh-workers