Re: [Tracker] Vala binding

[Jamie McCracken <jamie mccrack googlemail com>]

we will want to create a new libtracker in vala (rather than c) that
wraps the dbus api

we will need to keep the old one on for backwards compatibility so the
new one should be parallel installable

jamie



On Thu, 2008-07-31 at 12:06 +0200, Philip Van Hoof wrote:
> On Thu, 2008-07-31 at 11:03 +0200, Philip Van Hoof wrote:
> > Is it ok to add a vala binding in src/libtracker in indexer-split ?
>
> By looking at the generated binding, I noticed that the API in tracker.h
> has a few serious flaws and problems:
>
> * It pretends to be GObject-like, but it's really one big facade API for
> TrackerClient (so the only object that we can make out of it, is
> TrackerClient). The parser noticed this and decided to make static
> methods for all instead of building different classes (I can't blame the
> tool, that's about the only thing you can do with this kind of API).
>
> It should probably be like this:
>
> class Tracker.Files, class Tracker.Search, class Tracker.Keywords, etc
> etc. Instances of those classes must solve the "Tracker.Client" and the
> "Tracker.connect(foo)" stuff themselves internally (why bother the
> application developer with this anyway?).
>
> * Types like "char **" must be GStrv, else any binding tool will see
> such types as a by-reference passing. You get "out weak string" rather
> than "array of strings".
>
> * There are GPtrArrays being returned. Those will contain arbitrary C
> pointers, all typing will be lost and no Boxing will automatically take
> place. Meaning that the language binders must provide all that manually
> for each and every language binding. Much better would have been to use
> a collection API instead (http://live.gnome.org/IteratorsAPI).
>
> Even if those are always strings, then still by just looking at only the
> API you can't know. You also don't know who should free those, or what
> will free them if you don't need to do it.
>
>
> For example, without learning the internals of Tracker, how do I free
> the results of this one?
>
> GPtrArray * tracker_keywords_get_list TrackerClient *client, ServiceType
> service, GError **error);
>
> And "get_list", what does that mean? What will be in there? How will it
> look? Strings? How do I know for sure? And if it's strings, why not just
> return a GStrv instead? And why do other APIs that return arrays of
> strings do return GStrv and others GPtrArray?
>
> Right now some APIs are returning "char **".  The only reason why I know
> it's a GStrv-like blob of C memory is because there are sample tools in
> libtracker that use "g_strfreev (blob_of_c_memory)" on the returned
> value.
>
> It's not even documented in tracker.c as a gtk-doc comment. The typing
> is not a GStrv, just "char **", which can mean 15 things in C.
>
>
> My opinion: we need to rewrite tracker.h's API and make it all sane.