The usage statistics [kactivities, baloo, ktp, plasma]

[Ivan Čukić]

> No. It does store any info.

Does this mean that baloo does not search file names at all?

> The NTFS file system has something similar. It's called a USN Journal.
It's
> their solution to applications being able to see what changed when they
> weren't running or if they missed some events.
>
> I'm not too keen on Baloo doing stuff like this, but we can make something
> new which does stuff like this, and (possibly) make Baloo use it.

+1

This would mean essentially moving baloo's file change detection outside,
and
improve its powers a bit?

> I looked into the BTRFS file system about a month ago, and we could
> hypothetically use its snapshot feature to know what has changed since a
> particular time interval. Currently btfs-send, sending both the data and

The problem with this is that the snapshots should be *very* frequent then.
I'm not sure this is a good idea. Or potentially reporting non-changed
files
to the client when the snapshot was not recent enough for the requested
timestamp.

> Be careful here.
>
> * Silently failing is not always a good idea

When statistics are concerned, it is always ok to fail  Joking, but we can
not do any better than that.

> * Making file Indexing mandatory for statistics also seems a little bit

Indexing would be mandatory (or the separated service) just for the
moving/deletion detection - the rest would work as before.

Cheers,
Ivan

-- 
KDE, ivan.cukic at kde.org, http://ivan.fomentgroup.org/
gpg key id: 850B6F76

On 21 October 2014 17:18, Vishesh Handa <me at vhanda.in> wrote:

>
> On Tue, Oct 21, 2014 at 11:22 AM, Ivan Čukić <ivan.cukic at kde.org> wrote:
>
>> One thing to ask here is if baloo skips indexing a file that is in an
>> indexable folder - does it store any info about the file (name, date
>> etc.) or
>> not?
>>
>
> No. It does store any info.
>
> Still, baloo is not off the hook - if we want to detect the file moving
>> and
>> deletion (as suggested by the guy behind baloo :P), at least for the
>> indexed
>> files, we need baloo to somehow tell us what was moved/deleted.
>>
>> This could be implemented in a few different ways that would all have
>> some
>> drawbacks:
>> 1 - baloo sending signals - big drawback would be that if the clients
>> miss out
>> an event, the database would become inconsistent;
>> 2 - saving baloo ids along files in kamd - drawback is that baloo becomes
>> tied
>> to sqlite (as you mentioned);
>> 3 - baloo saving information about what has moved/deleted so that a
>> client can
>> ask for all events that happened since some timestamp - drawbacks here
>> are
>> that the clients need to regularly check for the updates meaning they
>> will
>> most likely have at least a bit out of date information
>>
>
> The NTFS file system has something similar. It's called a USN Journal.
> It's their solution to applications being able to see what changed when
> they weren't running or if they missed some events.
>
> I'm not too keen on Baloo doing stuff like this, but we can make something
> new which does stuff like this, and (possibly) make Baloo use it.
>
> I looked into the BTRFS file system about a month ago, and we could
> hypothetically use its snapshot feature to know what has changed since a
> particular time interval. Currently btfs-send, sending both the data and
> the metadata, but that can be improved. I'm not saying that we make btrfs a
> dependency for Plasma, I'm just throwing ideas out there which was can use
> IF the user is on btrfs.
>
>
>> 4 - combination of 1 and 3 - it would be the most complex implementation,
>> but
>> it would work properly (distributed dbs are evil  )
>>
>> And, an additional problem is what to do about the files that are not
>> indexed
>> by baloo? Should it silently fail or what? For the statistics, it would
>> be
>> (imo) ok to fail silently, but for activity linking, it might be nice to
>> show
>> a warning message to the user.
>>
>
> Be careful here.
>
> * Silently failing is not always a good idea
> * Making file Indexing mandatory for statistics also seems a little bit
> risky.
>
> --
> Vishesh Handa
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>


-- 
KDE, ivan.cukic at kde.org, http://ivan.fomentgroup.org/
gpg key id: 850B6F76
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20141021/ca618175/attachment.html>