~bitfehler/m2dir

1

Thoughts on m2dir

Details
Message ID
<hrf3fpdqp5yo5snef2lghfeavgqg42v2sccexfzds5b3qc4zx7@6wo44cx7rb76>
DKIM signature
pass
Download raw message
Hi there,

I align with your thoughts on Maildir, and M2dir sounds like taking steps in
the right direction. Any tool that takes a file as input won't care about the
changes, although MUAs like mutt will need dedicated support.

For context, I maintain vdirsyncer, a tool to synchronise calendars and
contacts. Aside from CalDav/CardDav, it supports the Vdir Storage Format[1],
which has some very simliar ideas: each directory is a calendar which contains
files with one event each (or a series of recurring events). M2dir feels very
close in spirit, and hopefully both specs can learn from each other (I plan to
publish the vdir specification as a standalone page to encourage adoption in
related tools).

[1]: https://vdirsyncer.pimutils.org/en/stable/vdir.htmlk

I don't fully understand the purpose of explicitly declaring an m2store or
requiring the .m2store marker, especially if an m2dir can be moved elsewhere
and should still be usable as such. Why can't m2dirs just be put into a regular
directory and be operated on directly?

Regarding the .delivery approach, I can't say that I'm convinced by it. Why not
deliver to the INBOX by default, and let users make customisations via Sieve?
Sieve lets users define flexible configurations, for example, delivering emails
to different mailboxes (m2dirs) depending on sender, subject, List-ID, etc.
This bit of the spec seems to overlap with Sieve, but providing only a tiny
portion of its functionality (e.g.: changing the default delivery for ALL
messages).

I like the fact that filenames don't change, and saving flags into a separate
file sounds like it brings about flexibility that is entirely missing on
Maildir. Do you think that notmuch will need visibility into those at some
point?

While working on vdirsyncer, I've tried to leave room to eventually use is sync
algorithm for email as well. I think m2dir would be a better suited target than
Maildir. Both caldav and vdir have immutable paths for each item, so vdirsyncer
assumes that paths are immutable. It also saves properties into a separate
file, so saving flags like this is a great fit too.

Thanks for tackling this endeavour! I'm quite curious to see where this will
lead.

Cheers,

--
Hugo
Details
Message ID
<fa4941d8-525e-47c0-a798-10e6154f047c@bitfehler.net>
In-Reply-To
<hrf3fpdqp5yo5snef2lghfeavgqg42v2sccexfzds5b3qc4zx7@6wo44cx7rb76> (view parent)
DKIM signature
pass
Download raw message
Hey,

responses inline, I hope they make sense.

On 4/16/24 11:44 AM, Hugo Osvaldo Barrera wrote:
> I don't fully understand the purpose of explicitly declaring an m2store or
> requiring the .m2store marker, especially if an m2dir can be moved elsewhere
> and should still be usable as such. Why can't m2dirs just be put into a regular
> directory and be operated on directly?

They can. The concept of the m2store is only to allow applications to 
derive information from the folder strucutre. If you have a folder "foo" 
(that is an m2dir) inside an m2store, it means that this name maps to a 
folder in a remote mail store (e.g. IMAP). You can put that folder "foo" 
any other place, the messages inside it will be just as usable, but that 
context would get lost.

> Regarding the .delivery approach, I can't say that I'm convinced by it. Why not
> deliver to the INBOX by default, and let users make customisations via Sieve?
> Sieve lets users define flexible configurations, for example, delivering emails
> to different mailboxes (m2dirs) depending on sender, subject, List-ID, etc.
> This bit of the spec seems to overlap with Sieve, but providing only a tiny
> portion of its functionality (e.g.: changing the default delivery for ALL
> messages).

Why not INBOX -> because that is an IMAP concept. The spec also does not 
prevent using sieve. It says "if the directory is a valid m2dir, deliver 
the message there and be done". So it a user has their mail delivered 
through a sieve client (which would have to support m2dir), the outcome 
would likely be exactly that: some directory that is a valid m2dir, and 
it can just be written there.

The default delivery target thing was only to establish a total baseline 
for delivery that is independent of anything else.

> I like the fact that filenames don't change, and saving flags into a separate
> file sounds like it brings about flexibility that is entirely missing on
> Maildir. Do you think that notmuch will need visibility into those at some
> point?

Yes, notmuch would need proper m2dir support to be usable on top of it. 
I took a brief look at notmuch, but unfortunately i didn't find the code 
very easy to work with. And honestly, my goal is much rather that I can 
ripgrep through my mails. Notmuch support would still be amazing, of course.

Cheers,
Conrad
Reply to thread Export thread (mbox)