During some recent testing and work with Lucene, my coworkers and I have noticed some things in Lucene's guts that I wanted to ask about.
Directory is currently an abstract class that claims in its javadoc that "Directory is a flat list of files", then goes on to describe non-"flat list of files" based implementations (JDBC, RAM, etc). Is it worthwhile to split out Directory into a top level interface, and possibly have the existing abstract class be a FileBaseDirectory instead? My primary consideration (since I'm new to the code) is the number of references to methods like "fileExist" on directory, and their usage of those methods. They look like they won't work with non-file-based Directories (like DocumentsWriter?). Is that true? Pointers? Tips? :) It seems like this would be more precise while also allowing for a more fitting interface (more encapsulated?) for non-file-based implementations. Thoughts? If this is not seen as crazy, I'll work on some patches. As a side note, are folks here open to cleaning up some of the older code to use "list" instead of concrete implementations and the like? Thanks --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
