On Mon, 2003-09-22 at 18:40, Martin Sevior wrote: > On Tue, 2003-09-23 at 08:19, Bob Smith wrote: > > On Sat, 2003-09-20 at 14:40, Rodrigo Moya wrote: > > > > <snip> > > > > > > > > > the data service is the best example so far. Since both gnumeric and abi > > > use libgda to get data... > > > > > > > Been thinking about this some more. Why does this need to be implemented > > as a plugin? The way each app uses the data source is different. So, > > that code is app specific so it cant be shared. It's an app specific > > plugin. The part that can be shared is libgda itself, and that's in a > > library. No need to make that a plugin. Where a data service would be > > useful is when you want to support nonlibgda data services. But then > > your really defeating the purpose of libgda. Libgda is a wrapper that > > abstracts the database implementation specific code from the nonspacific > > stuff. If you do this in GO, your just reimplementing lots of libgda > > again. > > > > In the case of AbiWord the plugins also serve the purpose of extending > the program to take advantage of the services available on the platform > of choice. > > libgda is not available on Windows. By using a plugin we can provide > GNOME users extra functionality without having to port libgda to windows > and without a huge pile of #ifdefs inside abiword. > My argument was, you'd have to implement a database abstraction layer as a service. Libgda is more or less a database abstraction layer. So, you'd have abiword -> data service -> data service (libgda) -> database. why not just do abiword -> libgda -> database. The time it would take to port libgda to win32 would be less then implementing libgda over again. I think one of the things that I was thinking about was, plugins that need to be shared really should be libraries instead of plugins. Is this better? Cheers, Bob > Cheers > > Martin > > > <snip> > > -- Bob Smith <bob thestuff net>
Attachment:
signature.asc
Description: This is a digitally signed message part