> A function interfaced to the xs module would be find, but how about an
> object approach?
I feel more comfortable with the "classic" approach instead of the
object approach. But these are just my feelings. Perhaps I am
This is my second perl module and I am making it in the same way
I made my previous one.
I think the more important component is the C library. This is the
hard work. In fact, the xs module took just a few minutes.
Give me some days to get a decent library, then we can talk about
the way to get the best perl implementation.
> One thing that might be nice is that with this you could have separate
> modules for searching and for indexing. Normally you might say "use
> SwishE::Search;", but saying use "SwishE::Index;" or maybe just "use
> SwishE;" then you would get full function Swish in the same interface.
At this moment, I am only working in the search part of swish-e.
> BTW -- would being able to use the index header as a place to store info be
> any use? Could the index header be variable length? I'm not sure what
> people would put there, but it might be cool to be able to make up
> additional headers when creating the index. The index header format would
> have to be tagged or indexed, of course.
The index header is now of variable length. It consits of several
lines staring with char "#" and the label of the variable. Personally I
do not like this format because max length is assumed internally
by the code. I would rather prefer somthing like:
This is the storing way used for MetaNames, Propreties and Files.
This way is safer and faster and would make the code easier.
Received on Thu Aug 3 12:10:29 2000