Re: [Tracker] Indexer modules API afterthoughts

[Jamie McCracken <jamie mccrack googlemail com>]

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.

Agree to all above

jamie