RFC: Location for KexiDB and 3rdparty libs like sqlite

[Jaroslaw Staniek]

Thomas Zander said the following, On 2007-06-25 23:02:

> 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.

Well nothing looks especially true here. 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
2) adds KexiDB dependency to this plugin
3) packager moves the app's plugin to external package, usually marked as optional

>> 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?

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.

>>>> 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

See (**) above for the meaning of plugin in current context. I am using the 
term assuming you at least once installed and run Kexi. If not, describing 
details how plugins work is beyond scope of this topic.

> 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.

I mentioned "more layered design", so public API is far smaller. How changes 
in private API breaks BC for apps?

Would be good if you can only propose answer on my question provided in the topic.

>>> 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. 

No I do not move them. Drivers are in subdirs and are plugins since 2003. 
Every window class is an implementation of a plugin iface too (but we do not 
want to talk about non-KexiDB GUI stuff now).

> That leaves the design of 
> the core library and thus the exported APIs.

Again: It's a small API compared to internal.

>> 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).

Are you sure? I am perfectly aware of EBN warnings and 99% of these are either 
cosmetic or related to private API or related to _application_ (read: Kexi) 
itself, not any public library.

> 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 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.

> 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.

Look at my answer at the bottom of the previous post: the planned API will be 
smaller. But it will be also still object-oriented; so no, 5 monster class is 
a no-go.

> In other words; make the full database API a plugin 
> like all the drivers are going to be plugins.  

These are plugins already and from the very beginning.

> 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.
IIRC e.g. in KDE 4 KTextInteface has been simplified exactly because not every 
method has ever to be reimplemented.
Could you imagine plugin interface for, say, KDEUI lib? Why?
Example: Qt does not have QIODevice moved to a separate lib and QFile to 
another one. These are kept in the same lib.

I invite you to KexiDB presentation @ aKademy to get more info on the 
framework's basics.

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice: http://www.kexi.pl/en, http://www.koffice.org
  KDE3 & KDE4 Libraries for MS Windows: http://kdelibs.com, http://www.kde.org