Hi Eric,
Thanks for your reply.
Quoting Eric Charles <[email protected]>:
1. The support on windows has been asked and the answer has been
that the maildir de-facto norm does not support this.
Fair enough; if this document [1] is THE (de facto) spec, then its
scope is obviously narrow insofar as it's *nix-centric and I'm sure
Windows implementation was not considered by the author.
Nevertheless, barring this one technical incompatibility, I can't see
anything else standing against such implementation, can you?
If the rigidity of the "standard" is considered of such importance
that a deviant implementation isn't acceptable, then an alternative
could be to clone/extend it, implement the necessary character-switch,
and call the result something else (AwesomeDir, whatever) to avoid
confusion ;)
2. Where is the [1] you are referring to? Btw I think we could make
it configurable to allow the mailbox-maildir to use a
windows-friendly character. Maybe that character has already been
proposed somewhere else? The default would of course be the standard
norm.
Sorry about that, I cut but forgot to paste... That link was just to
the maildir subfolder in the svn repo; instead of that, here's a
patch! Not sure if it's the preferred format (and is against 0.4
version, not trunk, as my test target initially will be the server
3.0beta4 release) but should be apparent what it does at least.
(Actually it does exactly nothing functionally different, but
replacing all hard-coded references to the colon with a constant
that's easier to flip.)
I've seen semicolon and (I think) comma suggested in the pages I came
across, but really it matters little as long as it's not a colon,
other NTFS/FAT reserved character, or character that could appear
elsewhere in the filename - which leaves us plenty of options. James
can't be the first project to have wrestled with this particular
conundrum when porting to Windows, so it might be the case that there
already is a favoured choice among those projects, but I'd need to
investigate further.
Certainly there would have to be a different default for Windows
because the global default simply doesn't work there, but many users
wouldn't care what character was used instead, so that decision ought
not to be forced on them.
Next I'll look into implementing an OS-detecting switch for this and
an optional preference to specify the character used. I realise this
remains very hypothetical for actual submission, but does that sound
like the best approach?
Thanks,
Robin Bankhead
[1] http://cr.yp.to/proto/maildir.html
On 14/08/13 16:11, Robin Bankhead wrote:
Hi,
I've been looking at James as a replacement for our legacy Windows- based
email setup, at which point my hopes of a maildir-based message store
were dashed (because of a filesystem reserved character (colon) in the
spec).
Moving to maildir appealed to me because the legacy software uses mbox
but the local spool is now up to nearly 2GB and the risk of corruption
is starting to bother me (well, that and the next Windows update could
render that abandonware unusable). I daresay it would improve
performance somewhat as well.
I've had a look at the source, and from what I can see, the edits
required to use an alternative character (eg semicolon) in message file
naming only amount to a couple of lines, or a bit more to make it a
configurable option.
I'm ready to try building and testing a patch myself, but before I fling
myself into that I felt it sensible to ask:
1. Has this been proposed before, and if so, are there technical reasons
why it was decided against? (No sense in going over old ground)
2. Should I be looking further afield in the source than the specific
Maildir code, i.e. the contents of [1], for potential conflicts? (I
guess in theory the answer should be "no", but y'all know the codebase
better than I!)
Any advice would be very welcome.
Regards,
Robin Bankhead
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
