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

Sun Jul 15 11:56:58 BST 2012

On 15 July 2012 12:13, Boudewijn Rempt <boud at valdyas.org> wrote:
> On Friday 13 July 2012 Jul, Jaroslaw Staniek wrote:
>
>>
>> Krita drags ODF (instead of e.g. ligher rich text component), the rest
>> is a result of this.
>
> No. Not necessarily, not automatically. There is no reason for the rest of calligra to bear the costs of having a database.
>

I am answering now, but boud, I propose to continue discovering what
calligradb is on the IRC meeting, this discussions goes out of sync
with different areas covered at once.

Packaging db access/creation lib for reuse by calligra modules does
not create database (even if empty db is a ~16 bytes file). No need to
confuse these domains at all.

>> Boemann proposed a thin interface that would
>> allow to disable the Biblio functionality in apps that need to consume
>> only partial ODF implementation.
>
> Yes, that could work. The text shape is shared by all of calligra, bibliography is only relevant for words, so only words should add that dependency.
>
>> Regarding comparisons to the new Amarok and Kontact 2 (Akonadi user),
>> let's *do not confuse* two things.
>
> Users see a database depencency. Users complain.
>

evidence, please, evidence: posts on the forums, lost business deals,
locked workstations...

>> The apps are spitting errors on me
>> because they misconfigure mysql embedded databases on startup, and
>> they have unfinished migration infrastructure from Kontact 1.
>
> And then they get errors, too, and get even more pissed off.
>
>> No
>> single complaint tha counts for these apps is related to size of
>> dependencies in the first place.
>
>
> That's because you decide that those complaints don't count. Which is your opinion, and you're entitled to it, but it doesn't mean that those complaints don't count. They do. I care about those users.
>
>> 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.
>
> Sure, that's fine. As long as krita users don't load an sqlite database they don't have any use whatsoever for.
>> > 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.
>
> Not my userbase. My users install krita. Not your users either, they are the people who install kexi. They don't install the metapackage. And I am fairly confident that actually most users who use things like ubuntu's software center install even words separately.
>
>> 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.
>
> That is completely and utterly irrelevant. I am making software for real users. They see the dependencies and complain to me. They are unhappy and they waste my time. Now if distributions wouldn't actually show what gets installed, the problem would probably be gone mostly.
>

Sorry, we cannot have conclusion here, since for me there is contradiction:
- making software for real users
- they see the dependencies and complain to you

We cannot agree that these are THE real users. In my entire career I
know these metrics do not count outside of domains like kernel
programming and embedded/microcontroller modules for refrigerators...

Please link to reasonable feedback from user base, I have only seen a
single rants from someone that are apparently never satisfied (unless
we remove Qt, unicode lib, KDElibs, and what not). These specific
types do not count for me because they apparently have no real work to
do.

> But I still don't want even a hassle-free database that users haven't got any use for when they start Krita. That just makes no sense.

There are efforts now (happen on IRC) to agree how to split the big
calligralibs package. Better to be productive there. Nobody even
suggested to load database in runtime for Krita...

>
>> 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.
>
> Fine. For people who need the bibliography stuff. In other words, a subset of Calligra Words users. For all the others, the whole discussion should be irrelevant. Because they don't need "reasonable data handling", since they don't need data handling at all.
>
> In other words, a feature that is useful for a single application should only impact that single application.

Please let's do not confuse biliography with calligradb.
I'll repeat, calligradb is something Kexi uses too in 2.5 of course
(that's the origin) and also any data sharing in Mail Merge will,
Sheets' data exchange (I mentioned that not once) needs it.

Keeping bibliography for Words only is right thing IMO and a business
of Words' maintainer -- moreover and this effort already progresses
well. So I really see no need for panic.

>
>>
>> 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).
>>
>
> Er, no. Calligra as a whole is irrelevant. It's not what Krita users install. And even if they install all of calligra, on startup, the number of libraries actually loaded should be minimized because of very real performance issues.
>
> So, it used to be that offering the table shape dragged in all of sheets on startup, I fixed that by making two-stage loading possible. We could use that for the text shape, to avoid dragging in a database, but frankly, that's the wrong place. Everyone uses the text shape plugin, so the text shape plugin should only drag in the extra libraries that are useful in one application when running in that application.
>

If I understand correctly Boemann addresses this, so there's great
dedication. Libcalligradb is about providing the single implementation
of optimized data storage in a place of multiple copies. The goal is
to have common storage format for relational data - that's beyond of
what ODF defines.

>> 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.
>
> I am not in the business of re-educating users. I am in the business of providing software they prefer to use over other alternatives.
>

I asked - please share the metrics with me. I see no evidence that
optimizing disk space is anything more than mental exercise. Example
of such largely failed efforts was presented yesterday by Martin
[http://blog.martin-graesslin.com/blog/2012/07/do-not-use-bleachbit/].

>>
>> Again, for non-office apps such as Krita the solution has been proposed.
>> And look, embedded/mobile targets are not 'affected'.
>
> Non-office apps aren't the only apps that have absolutely no gain from a bibliography engine. There is only one application that benefits, and that is words.

Please let's do not confuse biliography with calligradb, as I said above...

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