As to the backend: There is already a very powerful querying system. What it does is basically translate queries for MediaAspects and Attributes in MediaAspects into SQL queries, which are then thrown at our backend database. The database returns SQL query results, which are then automatically translated into MediaItemAspects.Sounds like a filter layer might be useful?
And the frontend already makes heavy use of it: Everytime you use the "Filter" button in the music / video or any other section in MP2 Client, this querying system is used. What happens technically there is quite complex, but as a rough simplification imagine the following: In your Video Section, when you "filter by genre" in MP2 Client, the client puts together a query along the lines of "give me all MediaItems that have a VideoAspect and group them by genres". This query is then transmitted to the MP2 Server (via UPnP by the way...). MP2 Server receives this query, transforms it into an SQL query, which is executed in the backend database. The result from the database is transformed into MediaItemAspects, which are transferred to the client (again via UPnP), where they are displayed in your video section.
So all this is already there and what we need to avoid the video section not to display Movies or Series is "only" a kind of "standard filter", which is always applied in the video section additionally to the filters you choose (I can easily say "only", because I have no clue on how to implement this on the client side - I'm a "backend guy" )
And while we talk about this, it is quite easy to explain some of the improvements that have been implemented lately and are implemented currently. Against the background of the above, imagine that you choose "show all MediaItems" in your music section, which contains, say, 20.000 music files. What happens is the following:
- MP2 Client queries "give me all MediaItems that have a MusicAspect".
- The query is transmitted to the server, translated into SQL and thrown at our database.
- The database returns 20.000 results, which are all converted into MediaItem objects with the corresponding MediaItemAspects.
- All 20.000 MediaItems objects (not the music files themselves of course, but the objects containing all the metadata about them) are transferred over the network to the client (assuming that the client runs on a different computer than the server).
- The client then "renders" all the 20.000 music items to be able to display them nicely on your client (rendering in this context means, it takes the cover image, puts the text below it and produces kind of a bitmap, which can directly be displayed on the screen just as you see it later)
- But finally you only see 10 or 20 of those items, because there is not more space available on your screen - until you scroll down...
But still, there is a tremendous overhead in that the database is queried for 20.000 items and the result is transformed into MediaItem objects which are all transferred to the client (potentially over a network connection). What helps here is "Data Virtualization". This means that the client can not only query for "all MediaItems having a MusicAspect", but it can say "give me the first 50 MediaItems having a MusicAspect". Later when the user scrolls down, it can query "give me the next 50" and so on. This is what Valk is currently working on and which will improve the user experience greatly - by way of again much better responsiveness.
These are just two examples of what I mean with "having the technical concept perfectly right". Once Data Virtualization is implemented, EVERY part of MP2 will automatically take advantage of this, because every part of MP2 uses the same way to communicate with the server.
Hope that explains a bit what we mean with "work to do in the backend"