[calligra] /: Move core parts of KexiDB lib to libcalligradb

Fri Jul 13 11:47:50 BST 2012

On 13 July 2012 11:28, Boudewijn Rempt <boud at valdyas.org> wrote:
> On Friday 13 July 2012 Jul, Jaroslaw Staniek wrote:
>
>> It was announced and put as RFC on 3rd July:
>>
>> http://lists.kde.org/?l=calligra-devel&m=134135216226096&w=1
>
> Sorry, but that was completely unclear. Clear would have been "proposal for adding sqlite and icu as dependencies to all calligra applications". Yes, you cannot rely on people clicking on a link that just talks about minutes for an irc meeting for words. Something that says "Just published minutes from the meeting - KexiDB adoption in Words Biblio module:" is not request for comments. It's a report of a meeting that probably is irrelevant for everyone who's not working on words' biblio module, or even not working on words.
>
> And yes, I am sorry, but I am way too busy to check every review request thoroughly and follow every link. If you want to do something that touches what I am working on, you have to be explicit in your communication or I will miss it.
>
>> At that time involved developers exchanged our concerns, cleared up,
>> and the still was in a form of idea. 4 days after it materialized as
>> review request.
>
> And now the "uninvolved" developers are a bit surprised, which should not surprise any of the "involved" developers.
>
>>  As you see in my original reply I provided data on what most users
>> already have on their systems: they have libsqlite almost for sure,
>> and will have to keep ICU lib in the near future.
>>
>> I would not exaggerate the dependency aspect before we formulate the
>> demand of lightness (maybe with help of users and statistics).
>
> Already I have to defend that krita drags in so many dependencies. Dragging in a database for a paint application is indefensible. Whatever people might already have on their systems. We'll get the same problems amarok and akonadi have to endure, which, as with amarok and akonadi have seen means users stop using the software.
>

Krita drags ODF (instead of e.g. ligher rich text component), the rest
is a result of this. Boemann proposed a thin interface that would
allow to disable the Biblio functionality in apps that need to consume
only partial ODF implementation.

Regarding comparisons to the new Amarok and Kontact 2 (Akonadi user),
let's *do not confuse* two things. The apps are spitting errors on me
because they misconfigure mysql embedded databases on startup, and
they have unfinished migration infrastructure from Kontact 1. No
single complaint tha counts for these apps is related to size of
dependencies in the first place. These errors are in no way related to
libcalligradb usage in both Kexi and Words, because we're talking
about maintenance-free sqlite. The one that's running on your N9 phone
in the background, I am sure. This thread is not about anything but
sqlite database plugin on top of libcalligradb. Other backends stay in
kexi/kexidb/ for a reason. And libcalligradb-based storages are based
on zero maintenance too.

>> Before
>> that the demand looks for me a bit like the demands of dropping
>> dependencies on KDElibs and stay 100% Qt-only (this is popular request
>> from time to time in comments whenever we announce another Calligra
>> version).
>>
>> I hear that Bibliography is a tier-1 feature of ODF and ODF is core
>> functionality.
>
> If it is, it's only for ODT. So only for words. Not for any of the other Calligra applications.
>
>> What's in ODF specs influence our architecture, we have
>> rarely discussions on skipping some ODF parts. I see a need to be more
>> active when it comes to features out of scope of ODF, such as
>> higher-level integration (and data handling, topic which was skipped
>> in the final ODF 1.1 for purpose).
>>
>> Otherwise, please let's find convincing cases, not corner-cases, when
>> given user group intentionally degrades functionality this way on a
>> desktop system. Sure splitting everything to plugins is possible. The
>> question is not 'how' but 'why' and 'what'. I am afraid the voices
>> demanding fragmentation of the packages of are the loudest ones, but
>> not represent real user base.
>
> Why do you think that? Who do you think the real user base of calligra are?

Those are people that actually view or write documents, not fans of
optimizing disk space for nothing, not admins that tinker with every
single dependency - why? - to win the contest on the smallest app at
Amiga demo party? :)
Most obviously I think about people that will install full calligra
metapackage, and they expect they're done. On desktop, everything
besides that case is premature optimization. Computation related to
metadata and installation process of a separately packaged library is
a bigger overhead than the package content itself.

It's safe to say users want sane startup and runtime performance, sane
RAM  utilization. If you look at the case with Biblio, addressing
these needs are  core reasons why storage based on in-memory db with
random-accessible extremely compact file storage beats zipped-xml
solutions (performance, memory and storage size).  Re-writing zip
files with XML is the least performant approach, that gives when file
format is implementation-defined (it is in Biblio storage/cache).
Zipped XML was a no-go for current GSoC Biblio implementation (so it
is QtSql+sqlite based at the moment). Reasonable data handling is not
an extravagant feature, just some understanding is needed... If you
don't have time, just trust me.

In 2.6 before moving to libcalligradb, calligra as a whole already
depends on two sqlite access library implementations (kexidb+plugin1
for kexi, qtsql+plugin2 for Biblio). So the 'before' state is worse
(for given user base I defined above).

Also, let's know the scale. Example: Disk cache of my web browser
while I am writing this email  in gmail is 100s of megabytes. Still,
people (and KDE people!) use fat Google docs for the real work. This
hurts me in some way, not the output from apt-get install.

So to have full spectrum, please ask the users that criticize size of
dependencies for input. Please share the metrics that matter to these
people.

Again, for non-office apps such as Krita the solution has been proposed.
And look, embedded/mobile targets are not 'affected'.

-- 
regards / pozdrawiam, Jaroslaw Staniek
 Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org
 Qt Certified Specialist | http://qt-project.org
 http://www.linkedin.com/in/jstaniek