Jamie McCracken wrote: > On Wed, 2008-07-30 at 05:56 +0300, Ivan Frade wrote: >> Hi Jamie
Hi >> This FTS3 sounds great, and could help to remove a lot of "home brew" code. >> >>> All the above disadvantages can be sorted by forking FTS 3 and >>> including: >> well, "forking" doesn't sound so good. Specially talking about sqlite >> that moves very fast. I dont know the technical details but sqlite >> should have places to connect the parsing functions and scoring >> algorithms. Something similar to the "collation" functions for the >> traditional tables. If it didnt have those things, we can think on add >> them. >> > > it has no ranking at all in their index structure > > a fork is necessary to add missing functionality - the code for it is > pretty small and we would have to inline the source of it even if we > were not forking as its not built into sqlite so wont be in distros I have to agree with Ivan. I think forking should always be the last alternative. We will be missing out on all the improvements that the SQLite developers make. If the code is small, it should be easy to just have a patch which we keep somewhere and apply during the build phase and just keep SQLite code as imported. GnomeVFS did this sort of thing for some of its imported libraries. Doing this would also make it easy to upgrade our SQLite import when we want to update it and fold back fixes. But before all of this, have you asked the SQLite developers if they would be interested in a patch from us to add such functionality? I really think forking should be the last step. -- Regards, Martyn _______________________________________________ tracker-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/tracker-list
