Opened 14 years ago
Closed 4 years ago
#535 closed enhancement (fixed)
Vala bindings
Reported by: | rc | Owned by: | Olly Betts |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Xapian-bindings | Version: | |
Severity: | normal | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Operating System: | All |
Description
Vala is a very exciting new programming language used a lot in GNOME. Since it compiles through C code, it is very fast compared to interpreted languages, often comparable to C and C++. It's designed around glib and gobject, libraries very popular with C developers. Many of the advanced object types such as lists of vala map to glib. The biggest drawback is that it requires bindings for external libraries. And while it includes a tool to generate bindings for GObject based libraries, other bindings require some manual work.
It would be nice if you could also provide a vala .vapi for Xapian. I'm pretty sure the Vala developers will be happy to assist you. I've not really used vala much yet, so I doubt I will be able to do this on my own, in particular since Xapian is C++ and there might be a smart way to map this to the also OO language vala.
See: http://live.gnome.org/Vala http://en.wikipedia.org/wiki/Vala_(programming_language)
P.S. Thank you for this great library. I've used it from Python for some projects, and I'm *very* happy with it.
Change History (5)
comment:1 by , 14 years ago
comment:2 by , 13 years ago
Apparently (see http://www.mail-archive.com/vala-list@gnome.org/msg07189.html ) this is currently not particularly easy. I can see two paths here:
- Create a plain C (or GObject) binding for Xapian. This should then be straightforward to wrap into Vala. This would probably be best done by the Xapian developers, since they know a lot about Xapian and can design a reasonable C API I guess. It might even be possible to do this using SWIG?
- Enhance Vala to support C++ libraries (see email list above). The Vala people obviously have some interest in that, but I figure it becomes quite hard and intrusive. When this has been successful, creating Xapian bindings should again be a lot easier.
comment:3 by , 13 years ago
SWIG releases can't currently generate C bindings for a C++ library. There was a GSoC project (in 2008 I think) which implemented this, but it isn't yet merged to SWIG trunk. But I think the status is that it mostly works, so getting that finished off and merged would be one approach.
People ask about C bindings from time to time, but experience with the Perl XS bindings and the Java JNI bindings shows that having to hand update bindings means they lag behind, particularly with wrapping new API features, because that's such tedious mechanical work. It needs somebody with the enthusiasm to actively maintain them for that to work.
Adding Vala support to SWIG would be another option. SWIG does a lot of the hard work of parsing C++ API headers, etc already, and xapian-bindings already has a lot of machinery set up for SWIG.
comment:4 by , 10 years ago
https://github.com/endlessm/xapian-glib seems to provide the GObject binding needed for path 1 in comment:2.
comment:5 by , 4 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
xapian-glib provides a .gir
(GObject Introspection Repository) file which can be used with vapigen to automatically generate Vala bindings to Xapian:
https://wiki.gnome.org/Projects/Vala/Bindings
So I think we can regard this as having been addressed and I'm going to close this ticket.
Thanks for you interest.
Past experience with adding languages to the bindings has shown that it's much better if they're done by someone who's used the language enough for them to know what feels natural in an API for that language, so the result is something which users of that language will actually love using.
Personally I also lack the spare time to take on something like this right now.
Also, if the wrappers need manually updating for every change to the C++ API, we really need somebody willing to take on that maintenance burden. The SWIG-based bindings handle many updates with no manual intervention, so they're fairly easy to keep up to date. The hand-coded Perl XS bindings require manual updates, and tend to lag (hence we're migrating to SWIG-generated Perl bindings). The hand-coded Java JNI bindings are a right pain to update, and so haven't been updated beyond the minimum to keep them working for some time (and we have SWIG-generated Java bindings under development).