RFC: Location for KexiDB and 3rdparty libs like sqlite

[Jarosław Staniek]

Hello,
KexiDB is a data/database handling library independent of Kexi or KOffice. In 
order to have it available for other apps (not only KOffice but e.g. a KDEPIM 
plugins, a KDevelop plugin, or a plasmoid, you name it) we need to move the 
stuff up somewhere in SVN.

The library will receive rather massive API changes and extensions, as it is 
developed in parallel with other apps, to suit their needs. So BC cannot be 
maintained as in kdelibs.
Other apps would not have problems with this as the support would be 
dynamically loaded.

Is kdeplayground safer solution?
I would like to avoid forcing devs to just copy the code as private like in 
ShowImg in KDE 3.

KexiDB can find its way for Kdelibs but in 4.1 or 4.2.


[1] http://www.kexi-project.org/docs/svn-api/html/namespaceKexiDB.html


-- irc LOG --
	jstaniek	hello David, I am looking at trunk/ and don't know what subdir would 
be well suited for placing KexiDB in (under a new codename) so that other apps 
can use it
	jstaniek	this is not kdelibs code at least not for 4.0
	dfaure	so it's koffice libs code? koffice/libs then?
	jstaniek	it's not only a framework for koffice apps
	jstaniek	it can be somewhat for KDEPIM, Amarok
	dfaure	well then it has to be in kdelibs - maybe for 4.1
	dfaure	so koffice/libs first, to make it ready for kdelibs, and then kdelibs 
for 4.1
	jstaniek	this was my first thought
	jstaniek	it obviously has to be even more shared; he apparently voted for 
performing 2 steps in one go and moving it out of koffice/ tree
	dfaure	the only place that currently exists out of koffice/ and is shared 
with other modules is kdelibs
	dfaure	(or kdepimlibs, which is unrelated)
	jstaniek	yeah. Somone not accustomed with the topic even proposed kdenonbeta 
on last akademy, but I think about packaging
	dfaure	1) kdenonbeta is dead 2) bad location indeed
	dfaure	you can't have it both.
	dfaure	you can't have something that is used by all modules,
	dfaure	and that doesn't respect contrainsts of binary compatibility
	dfaure	this means hell down the road
	dfaure	so either A) it's not used by other modules yet (koffice/libs)
	dfaure	or B) it's used by other modules _and_ it's ready for BC and other 
kdelibs requirements -> kdelibs
	jstaniek	if that's ok, I would go with kofficelibs (my initial proposal), so 
people will depend on kofficelibs package what is not huge requirement
	dfaure	depending on kofficelibs is also a problem, because koffice is not 
released with the rest of KDE/
	jstaniek	how about kdesupport/?
	jstaniek	as you know I have much code that's 3rdparty
	jstaniek	like sqlite
	dfaure	it's exactly the same: used by all modules, so it must remain BC once 
4.0 is out.
	dfaure	we expect the same quality of kdesupport code, it's just that it's 
packaged separately.
	jstaniek	so maybe my case re BC policies and packaging is simialr to 
kdevelop, so I can reside in KDE/{somenewdir} ?
	dfaure	you think kdevplatform won't keep BC??
	jstaniek	its BC is not KDElibs BC right?
	jstaniek	BTW the kexidb dependency for most apps would be weak, i.e. via 
optional plugins, as database support is optional
	dfaure	there's only one kind of BC :)
	dfaure	but I don't know the exact policies for kdevplatform
	dfaure	better discuss this in a larger group :)
	jstaniek	ok
	dfaure	I dislike how we are putting a high requirement on kdelibs and then 
finding ways to avoid that high standard for code that we still want to share...
	dfaure	what's the point of setting a high standard if we just find ways 
around it...
	jstaniek	what I need is an incubator place for the new KDE 4 iteration of kexidb
	dfaure	incubator means not ready for use by other apps (we can't have kde 
apps depending on moving API) -> koffice/libs
	dfaure	(or playground, but then you can't even use it in kexi)
	jstaniek	kdelibs were such incubator for longer than year, right? and app 
developers needed to track changes.
	jstaniek	at least kexi is moving as well as kexidb, other solution is to 
package snapshots of kexidb and/or provide alternative CMakefiles.txt in SVN
	jstaniek	(for so called standalone builds as before in kexi)

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