shared wasabi implementation

Jos van den Oever jvdoever at
Thu Feb 15 02:52:35 PST 2007

2007/2/15, Fabrice Colin <fabrice.colin at>:
> On 2/15/07, Jos van den Oever <jvdoever at> 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
> There's a mailing list at
> 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.


More information about the xdg mailing list