I personally find the file format documentation useful. I want to understand more than just the rough purpose of the file. If we don't document anywhere how is the file written, exactly, how can someone ever come up with a proposal for improvement?
I understand though that maintaining it separately from the javadocs is problematic. So I don't mind if we remove the fileformat page, but can we agree to document the format in the javadocs? I understand that even the javadocs might lag behind, but that is not a reason for not documenting at all ... I remember IW jdocs lagging behind and we fixed them. This is the same to me. And some Codecs will be better at their documentation than others, that's acceptable too. Shai On Tue, Oct 4, 2011 at 4:37 PM, Robert Muir <rcm...@gmail.com> wrote: > On Tue, Oct 4, 2011 at 10:33 AM, Andrzej BialecYki <a...@getopt.org> wrote: > > > So far the list of possible file names was relatively small and > well-known, > > e.g. people knew that a prx file contained postings, and its size would > > indicate this or that. We are going to have dozens of codecs soon, and if > I > > come up with a codec that creates, say, abc and xyz files then without > > knowing what they logically correspond to, it will be difficult to > > troubleshoot. Similarly, if I discover files abc and xyz in my Directory > I > > should be able to tell whether they belong there. > > > > I'm not sure about the latter part? this is not really possible unless > we make all of our codecs use "unique" extensions? Currently preflex > codec uses some of the same extensions as standard (e.g. .frq) for > example, but its definitely a different codec. > > > -- > lucidimagination.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
