From: Clinton E. <men...@cr...> - 2001-02-08 18:42:28
|
I had a bit of an idea at school today about mpkg's package database - - why go through all the work of setting up our own package database, when we could use an abstract interface to any number of db's. Let me explain. Ok, step one would be to write a library with database access methods for mpkg. Example: find_file(), find_pkg(), etc, that would be used when installing or finding packages to install(so the package manager would be able to find existing packages, available packages, and see what packages provide the files the package you are installing's dependencies,etc). Now, why write an entire database when all we need are these functions to access the database? There are many free SQL databases(postgre,mySQL,etc) that can be searched and have fields added too, so why not use them? My idea is to put all the functions headers in a header file, and then make the implementation a nice shared object -- just pop in whatever interface you wanted. The first of these would be a SQL interface(postgre or mySQL?). The functions would just wrap around the sql server interfaces, providing a standard method to access the package database. The eliminates are a large amount of work on out part, and also adds flexibility. Don't want to have your pkg database in a SQL server? Fine, use a flat text interface. Don't like that? Then use any number of interfaces to different package database access methods. See how this is a good thing? Implementing our own db format for the package database would be pointless and just add more work to the task of writing mpkg. So, does my abstract interface seem to make sense? ------------------------------- #indrema @ irc.openprojects.net be a part of the revolution. unknown_lamer |