Hi!, As a heads up, all the suggestions that could affect tracker module developers are already implemented in trunk, if you compile tracker with --enable-gtk-doc, you'll see the docs in:
tracker/docs/reference/libtracker-module/html/index.html I've also developed a new version for a sample dummy tracker module which could work as the base implementation for anyone who wants to make tracker index their application specific data: http://people.imendio.com/carlos/tracker/dummy-tracker-module-0.0.2.tar.gz Regards, Carlos On Mon, 2008-11-10 at 17:52 +0100, Carlos Garnacho wrote: > Hi!, > > Since a while ago tracker allows compiling external modules, so > tracker-indexer is able to collect data from external resources, here's > a list of things that could be considered to be improved: > > * Improve services/metadata definitions i18n. DisplayName, Description, > etc... should be translated. These also should be available to apps as > first class objects through the libtracker API, so we don't end up doing > strcmp() tricks like in tracker-search-tool so we get proper i18n, > etc... > > * Do not split URIs into dirname/basename from the API. this is a > problem if modules split differently URIs than what would tracker do, so > I'd just make this function return a full URI string so all uri > splitting in order to be stored is done the same way. > > * Way too much undeeded API is exported, we should devise what could or > couldn't be useful to the module API users, so the whole experience is > less confusing > > * Since we depend on recent enough glib, I'd encourage using GFiles > rather than path/URI strings generally, at least for the current > TrackerFile uses. > > * TrackerMetadata could offer API to store ints/dates/doubles/... and > transform internally these to the storage type (strings), instead of > forcing modules to do that by themselves. Also whether to use API for > inserting single elements or lists is unclear, since users can just > resort to either using common sense (which doesn't always work) or read > the .metadata files. > > As a possible option, we could have a helper app that displays > services/metadata types, descriptive names, and whether they take single > elements or lists, that could be helpful for developers. > > * A suggestion I got is to make the API fully GObject oriented, so it's > easier to wrap in other languages like vala [1] or python. I've already > got an idea of the best design if we were using GTypeModule+GInterface, > but could just be too effort and too late now, and also depends on > whether we want non-gnomies using the API or not, so I'm hesitant about > this > > Comments on any of the points, or further issues with the modules API > are welcome :), I really think we should get this nailed before this is > in a release. > > Regards, > > > [1] Note there's already a VAPI file for the tracker API, but it had to > be mostly handmade, > http://svn.gnome.org/viewvc/vala/trunk/vapi/tracker-indexer-module-1.0.vapi?revision=1839&view=markup > _______________________________________________ tracker-list mailing list tracker-list@gnome.org http://mail.gnome.org/mailman/listinfo/tracker-list
