shared wasabi implementation

[Jos van den Oever]

2007/2/15, Fabrice Colin <fabrice.colin at gmail.com>:
> On 2/15/07, Jos van den Oever <jvdoever at gmail.com> wrote:
> > Hello wasabi people,
> >
> > Shouldnt we start sharing parts of the code required to implement
> > wasabi? I'm mainly thinking about a struct in c representing a parsed
> > wasabi query and functions to de- and serialize these from either the
> > xml or the user language.
> >
> > This should be no more than a couple of files that we can put in an
> > xsd svn. Requirements to make it palletable for most: few deps and
> > written in c. For C++ fans we can add a small wrapper.
> >
> > What do you think? Can someone here open an svn project for this?
> >
> Jean-Francois and I have started a side project called Dijon, with the aim
> of facilitating code sharing between Recoll and Pinot. Our first target is
> filters, but this should eventually cover anything that comes out of the
> Wasabi project, which is actually why we chose the name Dijon ;-)
> The project's SVN repo is at http://svn.berlios.de/wsvn/dijon
> There's a mailing list at https://lists.berlios.de/mailman/listinfo/dijon-devel
>
> Both of us have been extremely busy lately and have not been able to
> work on it that much. Anyone willing to tuck in, for instance with
> toolkit neutral parsers for the query languages, get in touch.

Sound good. I'd prefer to have the code on fd.o itself, but we could
work from there too.

My initial idea is to start really simple with only the c struct that
represents the queries. Parsing from human language or xml should both
be done serverside. It would be nice to code this parsing only once.
For optimal shareability, I suggested to use only c first and add
wrappers later. I do not mean to have code for glib, qt or whatever,
that's not something that can be shared between a lot of projects.

What I mean is also not a library. By having it in svn it is
versioned. We can even have branches, but finally everybody will put
the code in their own project and not put it in a lib first. The lib
would be quite small and projects would be kept back by having to work
with a released version of the lib.

Cheers,
Jos