Hello, Peter:

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
>run like:
>   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 
name (IE, 
/a/dir/indexname.index/indexname.index.prop ) 
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 
method of 
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 :)

Josh
_______________________________________________
Users mailing list
Users@lists.swish-e.org
http://lists.swish-e.org/listinfo/users