RFC: Location for KexiDB and 3rdparty libs like sqlite

[Thomas Zander]

On Monday 25 June 2007 19:38:29 Jaroslaw Staniek wrote:
> Thomas Zander said the following, On 2007-06-25 16:21:
> > What problems do you see if the kexiDB code just stays in the same
> > subdir it is in now until there is a stable API?
>
> I being lazy about this, have been really hoping the lib can stay in
> koffice/kexi/.
> But people outside of KOffice would want to avoid checking out entire
> KOffice and/or disable compilation of apps. 

Further in this post you said that the other apps would have a compile 
time dependency.  In effect the location of where kexiDb is then has zero 
effect.  People can just checkout the kexidb dir if they want instead of 
koffice.
Bottom line; just because people don't want to do a full checkout is no 
reason to create a new top-level module.  Especially if you don't want to 
make it a library that keeps BC.

> What are your thoughts 
> about this regarding, say, Flake?

I don't see the relation to flake.

> I'd like to employ 'release early & release often' style during the
> development, if someone is interested, just like the kdelibs had before
> stabilization.

Why would location in svn have any effect on that?

> >> Other apps would not have problems with this as the support would be
> >> dynamically loaded.
> >
> > I don't follow this line.   Do you mean the other apps will not link
> > to the full kexiDb library?
>
> It's about moving dependency on KexiDB to a plugin. So there can be
> configure checks for KexiDB

Just for clarity; this is not what most people will think a plugin is.  We 
tend to call it a compile time dependency.
A plugin is something very different.
Your answer does leave me a little confused;  if it is a compile time 
dependency your line above makes no sense;
 "Other apps would not have problems with this as the support would be
  dynamically loaded."
Compile time dependencies are not loaded dynamically and even if they were 
the binary compatibility problems would still be there.

This in combination with your answer below leaves me to conclude that any 
source incompatibility has to be applied to all apps and any binary 
incompatibility will have a severe effect on all depending apps as well.

That should be very clear to anyone that wants to depend on it.

> > Question; Is it possible to have just a couple of classes public so
> > the gory details of connections and drivers are all hidden from the
> > public API?
>
> Yes, that's good design pattern. The new design for KDE 4, as I plan
> it, is more layered to address this. E.g. drivers/providers (plugins)
> require complicated API while apps using the freamework - do not. 

Hmm, if those drivers are plugins (I ask since you used the term 
incorrectly earlier in this post) then that means they can be compiled 
independently from kexiDB and also be installed independently and those 
drivers are then dynamically discovered and loaded at runtime.
Is that the case? Its good to know we agree on this usage of the 
term 'plugin' ;)

> Thus, 
> users (of applications) would be rather satisfied that only updating of
> drivers/provides (plugins) is needed after KexiDB API version changes,
> while apps can still work as these use a subset of the KexiDB API
> (which is also more stable part).

Ok, so you move several drivers to a subdir.  That leaves the design of 
the core library and thus the exported APIs.

> However, such things have to be developed and stabilized too.
> During the heavy changes, users of KexiDB could be prepared to close
> collaboration to get effects they expect; this is a price of
> integration at relatively high level.

Yeah, sure.
Bottom line is that kexi DB is currently very far from binary-compatible.  
If you look at 
http://www.englishbreakfastnetwork.org/krazy/index.php?component=bundled-apps&module=koffice
you'll note a good 500 issues.  And the d-pointer checks are not being run 
on kexi-db (ask Allen to enable those if you want to make it an exported 
lib).
If you are honest about it, you'll have to conclude it is foolish to make 
kexiDB a more public module right now, where it has to abide by a LOT 
more strict rules then the code has ever done.  I think it makes a lot of 
sense to fix all those issues first and foremost.
Or, to say it in another way;  if 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 the end; I'm still hoping that with the developers of those other 
applications you can design a small set of interfaces (say, some 5 
classes) so those apps can do what they want without actually linking to 
the full 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.

-- 
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/20070625/c80df5de/attachment.sig>