Re: [Tracker] Vala binding

[Philip Van Hoof <spam pvanhoof be>]

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.


-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be