I have spent a better part of the week and last week trying to understand GObject and the Glib type system which GTK+ and GNOME programs are based on. A bit challenging to understand since it involves some strong C fu to understand.
So what I've done so far is to create the constructor to making the new database, and then I will continue to start implementing the rest of the interfaces as defined by the application as what it expects from the database backend. There will be a lot of learning along the way.
I have talked with rhythmbox folks and while they aren't enthusiastic about the backend (they don't believe it will solve the speed problem). Both backends are "text" based since sqlite stores it's backend as a comma delineated file and the other one is xml based. There is nothing wrong with the current backend. Moving to an sqlite database gives you some small level of scalability, thread safety, and it simplifies the backend a lot since you're not implementing a database. Plus the pool of knowledge around sqlite is certainly going to be greater than the sum of knowledge for the rhythmdb xml database and thus adding extensions will prove easier due to good documentation on sqlite3. I don't expect the backend to be default or a patch to be expected. I'm doing it to learn and really that's all that is important.
However, one good thing is that rhythmbox will at least get some unit tests as in order to test the backend I need to be able to write something that only uses the rhythmdb object and implement simple tests to make sure things are working. That will probably be the first milestone since I can't really test the constructor or anything else until I have gotten this part working.
Milestone 1: implement the constructor and be able to load the database. Create a unit test program to test the constructor and the loading to make sure it is getting populated.
Milestone 2: implement the deleting the database, and the deconstructor and then update the unit test program to test the deconstructor. Additionally, start implementing the query interfaces. The query interface will probably the hardest part of the whole project.
Milestone 3: start hooking the parts to the main application and then see how things go from there. Hopefully things will start working. There will be issues with making sure that we can cancel operations or interrupt operations when we get to this stage. I would call it done at this point if we can get most of this working.
Milestone 4: If I have time, I will start adding the tagging feature to the database and then start working on hooking that up with a plausible GUI. Which will be awhile.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment