Re: [Tracker] Vala binding
On Tue, 2008-08-05 at 12:24 +0100, Martyn Russell wrote: > Jamie McCracken wrote: > > 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 > > Hmm, from what I have heard, if done correctly the vala generated C will > be binary compatible and should be API compatible too. Not sure why we > would need to keep the old one? It will be in version control of course. > the generated code would use gobjects not plain C ___ tracker-list mailing list tracker-list@gnome.org http://mail.gnome.org/mailman/listinfo/tracker-list
Re: [Tracker] Vala binding
Jamie McCracken wrote: > 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 Hmm, from what I have heard, if done correctly the vala generated C will be binary compatible and should be API compatible too. Not sure why we would need to keep the old one? It will be in version control of course. -- Regards, Martyn ___ tracker-list mailing list tracker-list@gnome.org http://mail.gnome.org/mailman/listinfo/tracker-list
Re: [Tracker] Vala binding
On Mon, 2008-08-04 at 10:06 -0400, Jamie McCracken wrote: > On Thu, 2008-07-31 at 11:07 +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 ? > > > > This will it be, if okayed > > > > sure although vala can easily access tracker api via dbus directly You are right. It turned out to be more easy to just use a dynamic DBus binding in Vala, than to wrap libtracker. -- 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 ___ tracker-list mailing list tracker-list@gnome.org http://mail.gnome.org/mailman/listinfo/tracker-list
Re: [Tracker] Vala binding
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. > > ___ tracker-list mailing list tracker-list@gnome.org http://mail.gnome.org/mailman/listinfo/tracker-list
Re: [Tracker] Vala binding
On Thu, 2008-07-31 at 11:07 +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 ? > > This will it be, if okayed > sure although vala can easily access tracker api via dbus directly jamie ___ tracker-list mailing list tracker-list@gnome.org http://mail.gnome.org/mailman/listinfo/tracker-list
Re: [Tracker] Vala binding
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 ___ tracker-list mailing list tracker-list@gnome.org http://mail.gnome.org/mailman/listinfo/tracker-list
Re: [Tracker] Vala binding
On Thu, 2008-07-31 at 11:07 +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 ? > > This will it be, if okayed With the difference that a tracker.deps will include dbus-glib-1, I forgot to add the file to the diff -- 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 ___ tracker-list mailing list tracker-list@gnome.org http://mail.gnome.org/mailman/listinfo/tracker-list
Re: [Tracker] Vala binding
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 ? This will it be, if okayed -- 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 valabinding.diff.gz Description: GNU Zip compressed data ___ tracker-list mailing list tracker-list@gnome.org http://mail.gnome.org/mailman/listinfo/tracker-list
[Tracker] Vala binding
Is it ok to add a vala binding in src/libtracker in indexer-split ? -- 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 ___ tracker-list mailing list tracker-list@gnome.org http://mail.gnome.org/mailman/listinfo/tracker-list
