Thanks for posting these questions.
At 12:12 PM -0500 10/19/09, Peter Karman wrote:
>I have been working on the 2.6 branch lately and have a couple of design
>decisions to make [...] I wanted to solicit feedback before I plunge ahead.
>My questions are:
>(1) the default behavior is to replace (overwrite) an index unless the
>-u (update) flag is present on the command line. This behavior seemed ok
>as a 2.4.x compatibility design, but in practical use it means that you
>have to explicitly tell swish-e *not* to erase your existing index every
>time you run it. [snip]
Since replacing indexes is what Swish-e 2.4 does
'by default', the least surprising thing would be
for 2.6 to do the same. Plus I wonder about
concurrency issues when updating indexes in live
use... has that åbeen tested? Is it expected to
work well in that scenario? Overall I'd lean
towards keeping 'replace' the default.
>(2) there are now many (6) files associated with a single index.
>Suggestion: make the index a directory instead of a file, so you would
> swish-e -f path/to/index.swish-e
>but index.swish-e is a directory, not a file.
(*) The least surprising thing (the thing most
like what Swish-e does) would be to give one of
the files (say, what's currently the
yourname.swish-e.head file) the exact name they
specified, and append suffixes to the others.
For one thing, specifying a directory as a target
for an index operation just feels semantically
wrong. Also, what would the six files in the
index dir get named? If they repeat the index
then that's awkward. Alternately, if I have a
whole bunch of files named index.prop
differentiated only by their enclosing folders
folders that's a little awkward too .
It would be convenient to have the index files
all in their own dir, but I'm leaning slightly
towards what I suggest above at (*).
Overall I think all the ways to go are kind of
awkward (I mean people really just kind of expect
one file per index), but that the current 2.4
appending-suffixes-to-the-ancillary-files is a
little nicer than the other methods overall. But
the current method, where not one file or folder
gets the same name as the index I specified, is
the least attractive of all :)
Users mailing list
Received on Mon Oct 19 15:07:56 2009