RFC: Location for KexiDB and 3rdparty libs like sqlite

Thomas Zander zander at kde.org
Tue Jun 26 16:19:15 BST 2007


Hi,

first a note; please don't let us all take a look at the kexi-definition 
of a plugin, as you suggested. The term is not an invention of kexi and 
it helps if everyone follows the same terminology (which I suspect, is 
not the case right now)

On Tuesday 26 June 2007 00:26:49 Jaroslaw Staniek wrote:
> The lib at stable stage will keep BC.
> And to use the library in external app, developer
> 1) creates a plugin in this app that only links to the app via a thin
> interface defined by the app, not related to KexiDB
[]
> > In other words; make the full database API a plugin
> > like all the drivers are going to be plugins.  
> > Those interfaces can then be placed in kdelibs or similar.
>
> Maybe some interfaces like tabular data handler e.g. for DDE can be
> provided.
>
> But why plugin for the whole library? There will be no multiple
> implementation of elementary idioms.

This bit sounds a bit iffy;  you don't want to make kexidb as a whole a 
plugin, but instead you suggest that each application that wants to use 
kexi defines a plugin interface and loader to allow the louse coupling.
So in essence the plugin structure has to be created anyway, but you think 
it should be reinvented by each and every app that uses kexidb.
I don't think that's a great strategy.

> f you want to make it possible for others
>
> > to use kexiDB, start by cleaning up the library and make it possible
> > to be binary compatible, add loads of API docs, fix the EBN issues,
> > finalize the APis for plugins (like the drives) etc.  One of the last
> > steps is to make it more public.  It should not be the first step.
>
> In cathedral development it would be true. But here it's high time to
> let people to be accustomed with concepts of the framework if they
> demand to, and work in parallel. I guess we're at middle step, not the
> first.

Are you implying that the reason you are mostly working alone on kexi (and 
kexidb) is because koffice is not a visible enough place?
I have my doubts that moving code will suddenly attract more developers.


Anyway; back on topic;

> > Why would location in svn have any effect on that?
>
> Because for a developer it's easier to compile a lib than grab 4 or 5
> classes out of an application (Kexi in this case), from various places
> within the directory tree, and compile that (but write custom
> CMakeLists.txt's before, rename namespaces to avoid clashes in the
> system...). This was the case with KexiDB before. Even then, using it
> in 3rd party app (ShowImg) helped to improve some interesting features.

Sorry, this just sounds like a red herring.  You agree restructuring is 
needed, but you say you need to move the stuff in svn because its a mess 
right now.
Ehm, then please just restructure and cleanup the API at the location it 
is now (koffice/kexi) and make sure the lib follows the high standards 
that KDE keeps for its public libraries. (see techbase for the specifics)
When we reach that point I suggest you write here again to look what the 
consensus is for a location.

For clarity; most libs / apps at the level of maturity kexidb is at get 
moved to the review module. I don't think its fair to ask for an 
exception.
-- 
Thomas Zander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070626/feecc7b1/attachment.sig>


More information about the kde-core-devel mailing list