First of all let me say this has been a nice 10 pages reading of witch I only lament one thing... the missing pages from the lighting.
It's been so long since I was hopping that XBMC will go to a centralized database... And now here they are the first steps.
I'm gonna test this as soon as I can get the svn to compile again (I had 28745 compiling yesterday but with today's adds it is not linking again
)
I, myselft are kind of a, let's say, advanced-experienced programmer with centraliced database systems (does SAP R/3 ring any bells) so for once I find a place I think I can contribute... or at least try.
Sorry if, for a first post, there are some questions that might been discussed or solved, but I will like to get up to date asap and try and help with evolving this.
1. In all this talk I have not seen any mention to transactional updating of the database and little consideration about concurrent updating. Is the concurrent updating taken into consideration in the new centralized design?
2. Also I saw the discussions in the beginning about how to manage the different client perspectives about file locations, but I didn't find any conclusion on that. I know for other things I work on (and by some vague indications by spiff) that a new URI is coming to the svn... can that be related?
3. Talking about pure database evolution (apart from db centralization and abstraction) I feel that XBMC media database lacks since always of a better object modeling. I will refer now to the movies object model. I must warn everybody that not being English native speaking might make this a lot more dificult for me to explain, but I'll do my best.
In the actual model we have a table for movies that store movie (as movie entity that has a title, a director, a production year, etc). This movies table has a field for a File that is (in my view of the model) an example of the movie.
If you want an object oriented programing analogy, movies will be classes (some how) and files will be objets.
The movie has attributes like title, director, year... etc.
And file has attributes like coded, resolution, languaje, etc.
The problem right now is that there is a correspondece 1:1 on movies-files relation when in the ideas world I can have one movie but many files of that movie (one in HD, another is a stream from the internet).
As you all know right now If we have 2 files for a movie that movie just appears twice in the database. And that can work, but it is not ideal.
There is some missing important information about a media database. For example: languages. One very important filtering data that is missing right know in XBMC is the language of a file. If I'm selecting a movie to see with friends, an important data for decision is the language as some people can't watch English or French or Italian spoken movies. That, of course is data associated to the file (not the movie. the movie can have a language as the original language, but that's it).
There are many more suggestions to do about db evolution (like to the paths table) but since there is a big DB evolution pending and there are some areas (lie the new URIs) that have to be uncovered to be able to give the best oriented suggestions I think I'll leave it here.
Again I want to end this with another thanks to all involved in this and asking forgiveness if this post is not best placed here.
Jur.