Hello Marco, > Hi, > > I have made the first small steps to be able to be able to use different > database backends in the same compiled binary. Just to be sure no > one else is working on the same code I just post here that I started > with no idea when it will be ready but as it seems I just need to > move some code around and write some glue code that select the right > database functions based on the database type selected. For now we > will probably start with a runtime selection of the database which > will load the correct shared object (e.g. I'm not going to put much > effort in the static versions of the dird those will be limited to > only one backend.)
Yes, much of the work was done by two things: 1. You adding shared objects 2. Implementation of the ODBI driver where all SQL engine dependent code was put on a variable so that Bacula could index to the right SQL for the db engine loaded. As you have noted, about the only thing to do is: 1. Allow multiple engines to be defined. 2. Build a separate shared object (dll) for each one ensuring that 3. Each has a different name. 4. Dynamically load the appropriate one at runtime. Be aware that some changes to the Windows code will also be necessary. I would very strongly recommend you to see if you can use the code that loads the plugins. Hopefully it can be adapted to load any Bacula shared object. It already has everything you need to find and load the sh or dll. > > As I think it will be quite an effort and we are doing a feature freeze > soon don't expect this to be in 3.2 but maybe somewhere early next year > it will go into the 3.3.x GIT branch. Also no promise as to when it will > be done. I have a rather heavy job next to my work on Bacula so its get > the attention I can spend on it. I still need to make a good design in > my mind but on a first read of the code I think I will drop the defines > currently in cats.h and write glue code for those functions there. Yes, this is something that for the moment we will want to put into a branch and then merge with the master right after the release of 3.2 > > Are we ok that we use dlsym and dlopen etc interfaces ? That way I can > reuse some of my knowledge I have on programming that interface years > ago on some other code I have written way back. Yes, but please see about the possibility of using the existing code to load plugins. > > So once again don't hold your breath, but please speak up if you already > started a similar effort and already made it trough a long way. > Duplicating the same effort would be something of a waste. > At the moment no one is working on this, so it is all yours :-) Many thanks. Kern > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Bacula-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/bacula-devel > Best regards, Kern ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
