RFC: Location for KexiDB and 3rdparty libs like sqlite

Jaroslaw Staniek js at iidea.pl
Tue Jun 26 19:45:11 BST 2007


Thomas Zander said the following, On 2007-06-26 17:19:

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

It should be reinvented by application developer as it resembles application's 
internals. It's one-to-many relation, kexidb is one library, applications is 
'many' side. There are multiply implementations of KexiDB, so what's the point?

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

These are your words not mine. There are plenty of code like Kate and Kross in 
public libs, that originated within specialized application (Kexi in the 
latter case).

I don't know you need some examples to get the idea.
As I am finishing the thread (parts of it could be continued on 
koffice-devel?), I'll give one example: CSV import/export. The only effective 
way to use the code and still have maitainable classes was to copy-paste from 
KSpread. Was there something wrong with KSpread? No. Just the CSV 
functionality had to wait for more users (apps) before it can be moved out of 
the shadow. I have CSV handling as a plugin in Kexi. Then, the code can be 
pulled back for use in KSpread (but via external library), KSpread as well 
dozens of apps that may need to handle tabular data.

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

???
TO use your words:
"Restructuring is needed, AND moving the stuff is needed in svn because [for 
now the library is located inside KOffice build system, despite the fact it 
the _code_ is not bound to KOffice, what also makes it impossible to package 
separately without conflicts with KOffice packages]"

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

Again this is a bit an invitiation to cathedral-style of development to me. 
But works rather go in parallel. For example the new iteration of KSpread's 
CSV support would not be ready before KDE 4.3 _if_ things are not developed in 
parallel.
I only asked RFC about such things to let potentially interested people to be 
more involved than 'cathedral' observers, and before something is developed 
100% to the specs.
Other example is ODF support -you know there's the same case in KOffice with 
partial ODF support, compared to more complete implementation (OOo).
The same with KexiDB.
So I cannot understand why making sharing the code easier could be a problem. 
I would rather see more - coordinated movement of the libs out of KOffice and 
relatively soon, so next iterations of KDE 4 apps will be even more modern 
than in KDE 3 (and ODF gives a hope for interesting improvements on this level).

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

I am almost sure about a need for the move no matter it will be a 'review' 
module or anything like extragear.

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




More information about the kde-core-devel mailing list