On Sat, 2004-01-24 at 04:07, Rob Shortt wrote: > Michael Ruelle wrote: > I agree with this as well, keep DB code and Freevo code seperate. The > use of plugins could play a great role here. It might be a great idea > to start by creating a dbplugin object for any potential database > plugins to extend, therefore we can define an interface there. I can > imagine several possible types of db plugins: > > 1) simple, local sqlite - fast. > > 2) client / server sqlite. we could wrap plugin #1 up in a helper and > xmlrpc server, this plugin shovels requests off to it. this would reuse > the code in plugin 1. > > 3) plugin for database X (mysql, etc), this too extends the dbplugin > object / interface. Your milage may vary. :) > > > This we can define the interface and not have to conform to some > > individual piece of SQL softwares view of what the standard is. And
Instead of multiple plugins/services for different databases, a 2-stage approach may be convenient where the major plugin/service implements the data interface in a business-object or webservice manner and uses a database abstraction layer. The 2nd stage then can implement the low level data access functionality. Low level objects rarely need maintenance, once written. Since transaction management is not needed, I have a slight preference for the webservice style for the service can run on any box w/o having to stub anything to achieve distributioness (but, I'm not very familiar with the functionality Python provides in this area). Richard. ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
