IRC discussion

Andrew Lake jamboarder at gmail.com
Sat Oct 25 13:08:17 UTC 2014


Thanks much for tracking this down Eshton.

Right so it looks like we're basically just doing our own internal data
store and bally will do its thing independently. We might use baloo for
basic searching but, with the custom structured queries we'll need to do,
it looks like we're doing own custom searching anyway. Not a problem at
all.

We'll probably go with SQLite as our local storage solution, unless others
have a different suggestion. We will likely have some complex queries that
will test the limits of SQLite but we can probably work around those limits
with multiple pass queries.

Andrew

On Sat, Oct 25, 2014, 1:50 AM Eshton Robateau <2607922181 at qq.com> wrote:

> Had a talk with Vishesh Handa on #kde-baloo, key pieces of info basically
> are:
>
> -Baloo doesn't store data any more (we were aware of that)
> -It can give a list of files based on query (using metadata)
> -It can also provide metadata if requested (of course we may want to
> provide our own)
> -We can write attributes to a file using its xattr
>
> -MOST IMPORTANTLY:
> <yungtrizzle> vHanda: would we need our own search plugin?
> [21:23] <vHanda> I'm not sure what you mean by "search plugin"
> [21:23] <vHanda> bshah: there?
> [21:23] <yungtrizzle> search store
> [21:25] <vHanda> okay. So during the KDE4 times and uptil about a month on
> in Plasma5, Baloo was trying to still be generic like Nepomuk and we had
> these concept of search plugins / search stores
> [21:25] <vHanda> they are now all gone
> [21:26] <vHanda> All Baloo can do it search through files for you
> [21:26] <vHanda> that's it.
> [21:26] <vHanda> We were initially planning on all those "Search Store"
> functionalities which will let other people export the search
> infrastructure and all
> [21:26] <vHanda> but then we realized we were going the wrong away, since
> no one was actually using any of that
>
> ------------------
>
>
>
> ------------------ Original ------------------
> *From: * "Andrew Lake";<jamboarder at gmail.com>;
> *Send time:* Thursday, Oct 23, 2014 4:45 AM
> *To:* "Eshton Robateau"<2607922181 at qq.com>;
> *Cc:* "bangarang"<bangarang at kde.org>;
> *Subject: * Re: IRC discussion
>
> Definitely. I think it makes sense to use Baloo wherever possible. I think
> we'll want to implement a Baloo Search Store to make our media data store
> searchable via Baloo. I'm sure Vishesh will be more than willing to help us
> understand how to do this. Baloo will cover only some of the functions for
> which we used Nepomuk. The rest we'll have to implement ourselves.
>
> Essentially our datastore will need to be able to store and make
> accessible:
> - All music file metadata (artist, album, genre, composer, track number)
> - Artist metadata (name, bio, rating, etc.)
> - Album metadata (release date, track count, primary artist, rating, etc.)
> - Genre metadata (genre mapping, rating, etc.)
> - Playback statistics
> - "Last-added" statistics
> - Audio stream/feed metadata
>
> Feel free to directly contact Vishesh with any Baloo questions and share
> whatever you find out here.
>
> Oh, if you get a chance, can you subscribe to the email list as described
> here:
> https://mail.kde.org/mailman/listinfo/bangarang
>
> That way your message won't end up in moderation waiting for me to approve
> it. :-)
>
> Hope this helps,
> Andrew
>
> On Wed, Oct 22, 2014 at 10:11 AM, Eshton Robateau <2607922181 at qq.com>
> wrote:
>
>> Nepomuk has been a important part of Bangarang but since it's
>> deprecation, our codebase has not ported away from it.  The obvious
>> replacement is baloo which has provided a solid api. Baloo allows us to
>> define and use relations for search store, file attributes can be directly
>> read/written using xattr.  See [1] for more details. Of course a wider
>> discussion is necessary and we might need to bring vHanda also.
>>
>> ------------------
>> [1] https://community.kde.org/Baloo/Architecture
>>
>>
>> _______________________________________________
>> Bangarang mailing list
>> Bangarang at kde.org
>> https://mail.kde.org/mailman/listinfo/bangarang
>>
>>
> _______________________________________________
> Bangarang mailing list
> Bangarang at kde.org
> https://mail.kde.org/mailman/listinfo/bangarang
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/bangarang/attachments/20141025/0f59e54d/attachment.html>


More information about the Bangarang mailing list