Re: [Tracker] What to do with libtracker-common?

[Carlos Garnacho <carlosg gnome org>]

Hey,

On Mon, Sep 29, 2014 at 11:55 AM, Martyn Russell <martyn lanedo com> wrote:

<snip>

 

Breakdown of libtracker-common
------------------------------

-> tracker-config-file.h

   Used for all GSettings/configs, so libtracker-data, libtracker-fts,
   tracker-store, and the miners.

The only purpose of this nowadays is to ensure the transition from keyfiles to gsettings, and will never be used after the keyfile is migrated and deleted.

IMO we should remove this and fully trust on GSettings API. Right now it can only hurt to people updating all the way from 0.8, and if any embedded system wants to use Tracker and has a trouble with gsettings/dconf, they will surely have the same problem with other parts of the stack, and can just use a different GSettings backend.

 

<snip>

 

-> tracker-file-utils.h

   Used to handle operations like getting file size, mtime, etc and
   also for locking files, calculating disk space remaining, etc. One
   important reason for APIs like tracker_file_open() is to make sure
   extractors open with O_NOATIME and to allow posix_fadvise() use
   consistently.

File locking should go, it's currently unused, and only plays well if you respect the locks, so it really isn't as useful.

 

-> tracker-ioprio.h

   Set the I/O priority to be lower than normal to avoid disk
   clobbering. Used by tracker-extract and the miners.

   Could actually be in libtracker-miner.

I would think this is too specific API, I wouldn't expect any external TrackerMiner to thrash the filesystem as massively as tracker-miner-fs does.

If tracker-extract and tracker-miner-fs are kept in the same repo, that could be private API between both though.

 

-> tracker-keyfile-object.h

   Internal and used exclusively by tracker-config-file.h. So wherever
   that ends up, so should this module.

Exactly, I think it deserves the same end...

 

-> tracker-locale-gconfdbus.h
-> tracker-locale.h
-> tracker-meego.h

   Used to notify and keep track of local changes which is needed to
   re-create database collations because sorting can vary by locale
   (among other things).

   The -gconfdbus file is an implementation, which we might even be
   able to remove by now? *Is anyone using still using GConf?*

   The -meego file is use to translate and get the locale on Meego.
   *Is anyone still using Meego?* Would like to remove this.

Please let's remove this outdated stuff, I consider on-the-fly locale change handling something unachievable today, no matter how much we tape over it

 

<snip>

-> tracker-os-dependant.h

   The tracker_spawn*() API here is only used by libtracker-data and 2
   extractors, mplayer and ps (where we use gunzip, which is quite a
   bad way to do this).

I really don't know why the PS extractor isn't using poppler... I would prefer us to stick to GStreamer and remove the mplayer module, it's practically unused in any downstream, after that it can be moved to libtracker-data, or just make it use g_spawn_async_with_pipes itself.

 

   The tracker_memory_setrlimits() is only used by tracker-extract and
   could be moved there directly or put in libtracker-extract.

Please let's just remove this, brings in enough grief.

 

<snip>

Possible solutions
------------------
1. We just make libtracker-common public, perhaps give it a better name (like libtracker-core?) and be done with it. We can then use it anywhere. Advantages: it's quick and easy, Disadvantages: API has to be stable.

2. We split libtracker-common up and move code to more specific areas, e.g. fundamental type functions (A) go into libtracker-data, etc. Advantages: code is more logically placed, Disadvantages: Linking to larger libraries for small API calls might not be so attractive.

3. We create newer smaller libraries with logical parts A to D and. Advantages: Smaller concise areas to group API, Disadvantages: Slightly larger maintenance and distribution burden in the beginning.

4. We copy the code to modules they're needed in. Advantages: Less libraries to link with, Disadvantages: potentially a larger footprint with the same API copied around.

5. Move libtracker-common to a separate git module, set it up on the relevant repos through git submodule, compile it statically in these repos, and add a configure script to that submodule that fails and points people to the right place(s).

 

Cheers,

  Carlos