On 16/08/13 18:36, Robin Bankhead wrote:
Hi Eric,
Thanks for your reply.
Quoting Eric Charles <e...@apache.org>:
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 ;)
WinMailDir?
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?
Rather than os-detecting system, the failing character could be defined
by configuration, default being the standard one.
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: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org
