> > - storing the data to be used/published via web-like services
> > - accessing one's own personal and/or work-related data
> >   (aka homedir and alike)
> > - storing mail (in Maildir)
> 
> It looks like in this list actual users are listed as #4 and #5, but the
> top priorities are sysadmin/package install stuff that can be done with
> something like rsync and a nightly cronjob.
> 
> > - storing mail (in Maildir)
> >   value of Coda: convenient, eliminates the need for an extra protocol
> >         (like IMAP) and extra authentication and authorization management,
> >         mail contents is consistently cached at the client/MUA,
> >         MXs can act in parallel instead of buffering/resending
> 
> Ignoring the 'minor' inconveniences of 4096 entry directory limitations,
> this is actually only convienient if your email application treats a
> Maildir folder pretty much like an IMAP server because building a simple
> index of all the email in a folder requires an access to every email. My
> inbox currently has 16864 emails, and that doesn't even include
> mailinglist traffic which is placed in their own respective folders.

~/Maildir [Msgs:59387 New:29291 Old:28054]

That is my status line on this mailreader. 

I gave up on coda and moved to AFS because I crashed it all the time trying
to do maildirs, and dealing with synchronization issues. Then I gave up on
AFS when I got tired of trying to split up my maildirs. What would help is
some sort of integrated mail delievery system (say CMU sieve) that can auto
start a new maildir when it gets unweildy. 

But you need to support at least say ~20k messages first. 

Right now, a $5/month debian VPS machine makes for a really great mail 
reader, with way more functionality and ability to find old messages than
what I get on gmail, the supposed 'king of search'

When the distributed filesystem can support this kind of mail storage, with
native (fast) support for at least one desktop-search applet is when that
filesystem will become a killer app. When that filesystem can support a mail
reader and native kernel-level client on Android or other mobile platforms 
as well is when we can all start charging $500/hour to provide professional
services to the hardware companies selling products and the service providers
offering storage solutions based on that filesystem.

> Moving to FUSE would be a much better approach if you want to get rid of
> kernel complexity. Patches are welcome.

Only if I can launch mutt and read in ~50k message maildir in less than 5
seconds, because every thing is already in the local cache.