Re: [Tracker] Tracker as digital asset manager

[Martyn Russell <martyn lanedo com>]

On 21/06/11 14:49, Age Bosma wrote:
> On 21-06-11 15:03, Martyn Russell wrote:

[snip]

> I'll try to explain it a bit more.

:)

> I'm talking about a desktop system. If the user installs Tracker
> manually, he expects, or could have expected, it to start indexing his
> complete system since that's basically Tracker's purpose.

OK.

> The same counts when the user installs a "FindEverythingOnYourSystem"
> application which uses Tracker as its core. In this case Tracker will be
> installed (if this isn't the case yet) as a dependency of the
> FindEverythingOnYourSystem application and start indexing the complete
> system. The user might not know that it is Tracker doing the actual
> indexing work, but in this case it does not matter.

The user would know but only if applications decide to inform the user. 
Tracker supports status for each data miner so you can know how long it 
will take to finish indexing your 1. Files, 2. Emails, 3. Flickr 
pictures, 4. Applications, 5. RSS Feeds and there are potentially other 
miners out there too which are not packaged with Tracker's code base.

You can see this with tracker-control -F, e.g.:

  http://fpaste.org/QTtK/

Ideally, applications which depend on Tracker should show some progress 
information so users know that their content is being processed and they 
shouldn't expect it to all be there just yet.

> When the user installs a "ManageAllYourPhotos" application which uses
> Tracker as its core, the user wants to work on just photos. When Tracker
> gets installed as a dependency, it starts crunching on all files by
> default. A performance peak of 2 hours as a result of it for just 10
> photos might not be considered acceptable. The same goes for e.g. the
> amount of permanent disk space usage.

:) Thankfully, our performance is no where near that bad. Though, as 
said before, hardware really makes a difference here. Saving to our DB 
can be faster with some file systems / hardware combinations.

Are you asking for figures on our indexing speed here?

> In this case you could limit the indexing by Tracker to specific folders
> or file types, or give specific folders or file types a higher priority
> as an alternative.

We do prioritise folders according to the order they're given in the 
config first and that's really only superseded if parent directories 
need to be processed first (because all folders have some parent - with 
some exceptions).

The order is seen in the fpaste above, it shows the XDG locations we 
handle and then the storage location is my removable media (handled last).

> When the user installs FindEverythingOnYourSystem at a later stage and
> the indexing was limited by ManageAllYourPhotos, he will only find its
> photos. Tracker was installed, there's no reason for
> FindEverythingOnYourSystem to assume not all was indexed in the first place.

Of course. But that's really why I asked what the target platform was 
here. That might not matter on an embedded system.

> The way I look at it:
>  From Tracker's perspective one should not limit the indexing but stick
> to the default. From ManageAllYourPhotos you'd better not limit the
> indexing at first start or at least present the user with choice,
> explaining the consequences. From a FindEverythingOnYourSystem
> perspective you should check what is indexed at first start and when it
> is limited provide an option to correct this.
>
> Does this sum it all up?

Yes.

I should add, just because we're indexing, doesn't mean you can't use 
Tracker. We handle queries during indexing quite well, much better than 
previous versions. The only concern is, what you're looking for might 
not have been indexed yet.

--
Regards,
Martyn

Founder and CEO of Lanedo GmbH.