MediaManager, week 2

Hey, so the second week is over, and I managed to complete all the tasks I set for this time! 🙂

== Work done this week ==

Until friday I’ve finished the first implementations of MMHitCollection, MMHit and MMFilter (though the last two do not do anything interesting yet). Also, I’ve spent quite some time setting up all the autofoo needs for the project, generating libmmanager.so.

Then, I’ve written a simple applications to test the backend side of the API and another simple one to query the results, and after a bit of struggling everything seems to work fine.

Starting from today, I’m working on the implementation of the filter side.  I tried to think a clever and extendible API for queryable attributes: so we have an extensible MMAttributeManager interface, which inside the library is implemented by MMAttributeBaseManager, MMAttributePhotoManager and so on, but it can provide any kind of attribute details, so it would be easy to write implementations for other kind of things. Its duty is to list and create all the possible attributes for a speficic media type. The atributes created by the manager should only contain a type, a name and a description.

So, a MMFilterParam is created, with a MMAttribute, an operator (equal, greater, less, …) and a value. By setting one or multiple MMFilterParams on a MMFilter you can actually query the application database to obtain your hit collection. Finally, a MMHit will contain an hash table of the MMAttributes with actual values relative to the object.

All of this is not yet implemented, though I started coding it today and some things are already there (untested).

== Plan for this third week ==

– Finish the filtering part.

– Code some “real-life” tests for the filtering API.

– (optional) Start investigating the D-Bus API.

I’d really like to finish the backend + D-Bus part until the end of June, to have the time to discuss it with someone at GUADEC and then have a full month for the GTK+ part and to iron out what’s wrong.

That’s all for now 🙂