Re: Proposed future for Tracker - Smaller modules

[Martyn Russell <martyn lanedo com>]

On 08/09/14 12:30, Matthias Clasen wrote:
> On Mon, Sep 8, 2014 at 6:34 AM, Martyn Russell <martyn lanedo com> wrote:
> > What is the goal?
> > -----------------
> > What I would like to achieve is:
> >
> > 1. Make it easier to build just what's needed (e.g. just
> >     tracker-store), i.e. more modular.
> > 2. Make development and maintenance easier by moving components to
> >     their own projects so development can be focused
> > 3. Make a clear distinction between *core* functionality and "nice to
> >     have stuff".
> > 4. I would like to unify the command line utilities a bit more
> >     similarly to how git operates, so instead of 'tracker-control -r',
> >     'tracker control -r', etc.
>
> But is it worth the downside ?

Good question.

>   - x times as much configure goo

I'm not so worried about the configure stuff, actually, I would like to 
have simpler files to work with :) the current configure script for 
Tracker is quite long.

>   - 2^x new module-module interfaces

I agree with you on this one.

>   - plenty of new opportunities for version skew and build breakage

So I mentioned a lot of reasons which are more personally related since 
I'm building and maintaining the project a lot. Let me expand a little...

5. The pace of development for some modules is quite different to others:

  $ git log --oneline --since=1.year src/tracker-store | wc -l
  8

  $ git log --oneline --since=1.year src/libtracker-miner | wc -l
  127

  Some places have no changes for a while now ...

6. Some use cases for Tracker are limited to a headless system where 
only the store is required, this makes half of the code base completely 
irrelevant. An example here is embedded cases like set top boxes. 
Companies could avoid patching OR building dependencies they're not 
going to use or don't want to use anyway making their footprint smaller too.

7. If I want to use a new feature as a developer working with Tracker, I 
should be able to build the module with that feature (e.g. 
libtracker-sparql) and not ALL of tracker. I guess this is related to 
your version fragmentation, but there are advantages too, like micro or 
regular releases for each component. I had an example like this the 
other day where I wanted to use the ontology from one branch but the 
binaries from another to test a bug.


Generally, I don't think it's a good idea to have huge modules (I did 
for a while) and that's one of the reasons I split out libmediaart, the 
code there (however crap at the moment), doesn't really change that 
often either and I can fix that independently and easily.

I am happy to listen to the community and decide based on input 
received, after all you guys are using Tracker and building it :)

Thanks Matthias,

--
Regards,
Martyn

Founder & Director @ Lanedo GmbH.
http://www.linkedin.com/in/martynrussell