Roman Rokytskyy wrote:

>
>
> > Right. The Google 'big' index isn't so big. The average
> > load/machine isn't quite high. But in which time frame can you
> > implement all the things needed to do this (ie. including
> > inter-server replication)?
>
> I guess you have understood me wrong - there's no point to compete
> Google and we're not interested in handling millions of requests on 8
> billion-document big database. Therefore no replication is needed.
> And even if we had such code in place, it would be useless to almost
> any our customer, since people are not ready to invest so much money
> into hardware.
>

Ah, sorry. This was intended to Jim because he wants to push the things
in that direction. I completely agree with you.

> > BTW, I don't want to compete Google, for the site of my institution
> > I rather prefer to have them to search my site which has a far
> > better search engine than I can build in ten years, I only want to
> > bring some very handful features in a reasonable amount of time to
> > my users (doesn't matter if their applications are desktop based or
> > web based, they have FB relational data as back end).
>
> There are already components that do exactly such thing (see for
> example FastTextSearch or components shipped with IBObjects).
>

Yes, but who's gonna guarantee that these will be supported in the future?
Also these aren't so fast than a b-tree engine inside. Also it will make
the FB more appealing. But, as I stated elsewhere if this thing is hard
to implement...

And also, it can be used to mix the keyword search with other FB
features in a single select.

hth,

m. th.

> > But, again, if you have plenty of development resources why you
> > don't port and/or adapt to engine Lucene and/or OpenFTS
> > (http://openfts.sourceforge.net/features.shtml
> > <http://openfts.sourceforge.net/features.shtml>)? These are quite
> > mature and with many advanced features.
>
> There's some issue with these two projects - they are written in
> Java. And additionally, using Lucene with Firebird requires some
> fixes for BLOB handling (implement seek for temporary blobs). The C++
> port of Lucene is not yet complete and I doubt it will ever be
> completed - more likely is that gcj-compiled library will be used
> instead. I have little experience with OpenFTS but their API was
> quite similar to Lucene.
>
> But the worst thing are the resources. We don't have them and
> therefore this feature is not yet implemented. I had a running
> implementation of Firebird-based Directory for Lucene that uses BLOBs
> for storage for more than 2 years and have pretty good idea how to
> merge Lucene with FB. But I have no time to do it myself. If you're
> interested in doing this job, contact me privately and we can discuss
> it further.
>
> Roman
>