Thanks for going through it, I know there's a lot to go through..<br><br><div class="gmail_quote">On Thu, Jun 28, 2012 at 4:45 PM, Mark Walters <span dir="ltr"><<a href="mailto:markwalters1009@gmail.com" target="_blank">markwalters1009@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I was thinking of just having one mail root and inside that there could<br>
be maildirs and mboxes. Everything would still be relative to the root.<br></blockquote><div><br>I'm hesitant to have directories that contain maildirs and mboxes. It should be possible to unambiguously distinguish between a maildir file and an mbox file (mboxes always start with "From ", no colon) but it sounds kind of fragile.<br>


<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
>  1. Are URIs the way to specify individual messages, despite bremner's<br>
>  concerns about too much of the API being strings? Is adding another library<br>
>  is the easiest way to parse URIs?<br>

</div><br>In my opinion  the nice thing about using strings is that it does not require<br>
any changes to the Xapian database to store them. I think using URIs may<br>
not be best though as they seem to be annoying to parse (as filenames<br>
can contain the same characters) and you seem to need to work around the<br>
parser in some cases.<br></blockquote><div><br>I think that's more the fault of the parser than of the URIs. If glib came with a parser, that would be great. There aren't a lot of options for pure-C URI parsing. Besides uriparser, there's also some code in the W3C sample code library, but it looked like integrating it would be a pain so I let it go.<br>

<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

I wonder if the following would be practical: use // as the field<br>
separator:<br>
<br>
e.g. mbox://filename//start_of_message+length<br>
<br>
I think 2 consecutive slashes // is about the only thing we can assume<br>
is not in the path or filename. Since it is not in the filename I think<br>
parsing should be trivial (thus avoiding the extra library).<br></blockquote><div><br>Can you explain what you mean when you say that two consecutive slashes can't appear in a URL? Ordinary filesystem paths can contain them, and so can file: URLs. (I just looked up file:///home/ethan///////tmp and Firefox handled that OK.) I've sometimes seen  machine-generated filenames with double slashes because that way you don't have to make sure the incoming filename was correctly terminated before adding another level.<br>

 </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

Secondly, I would prefer to keep maildirs as just the bare file name: so<br>
the existence of // can be the signal that there is some other<br>
scheme. This is asymmetric, but is rather more backwardly compatible.<br></blockquote><div><br>Based on your and Jani's reasoning, I did this. Revised patch series follows.<br>
<br></div><div>Ethan<br><br></div></div>