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

[Boudewijn Rempt]

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.

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

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

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

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

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

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

-- 
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl