 js, lucijan, 2003-10-19

!Why Kexi does not behave so good as KOffice application using kofficelibs compared to others apps from the family?


* Kexi, unlike (all?) others KOffice application is '''not''' document-driven
;: Kexi is project-driven insted. Thus it is conceptuall more like KDevelop.

* Application's environment.
;:Typical KOffice application is built upon the fact that there is a main document (that also can act as KPart) for application view, and most application logic is built around this single native format/mime type and KPart class that uses data in this single format.

;:Kexi has more distributed nature, there are more than just one mode (or two) for editing document or viewing it as read-only (both modes for e.g. KWord uses mostly the same KPart widget(s), only with disabled/enabled certain actions). Some Kexi KParts has editors that are built as strictly different components thant these used for viewing (example "table altering" dialog versus table/query data view).

* Storage differences
;: KOffice depends on storing its native format in single file (in some cases, it can be non-xml but still it is self-contained file)

;:Kexi has many storage options, since one of its goal is integration of external database systems. Kexi allows you to save short xml informational file (something like a shortcut to db connection) allowing you to connect again to database where your project is stored.

;:Other project storage method for Kexi is to use file-based databases (currently, bianary SQLite-compatible with Kexi system objects inside). For end-user convenience, such a SQLite database file can be self contained and no additional information (in additional xml file) is required (although it is possible to have one).

* KOffice behaves differently at opening projects than Kexi.
;: When not native format encountered, KOffice framework automatically invokes filters to convert a foreign format into its singe native format.

;:Kexi is not expected to do so: there is generalizetion developed inside KexiDB module; this module handles all differences "on-line". Otherwise it would be impossible to use Kexi: you don't need to convert e.g. MySQL-embedded-file to a SQLite file, since if there is a driver for MySQL-embedded it is still neutral to SQLite one.

;:Similarly, Kexi does not download all data from SQL server and then it do not converts its format to "common" data representation and then operates on this representation. Look that so called "filter chains" from KOffice framework could force Kexi to do so (otherwise owful wrapping should be added), while in most cases the only thing that is converted in Kexi projects (and rather on-demand) are database schemas.

;: Above notes do not mean that Kexi is designed to lack filters functionality. Kexi filters functionality is designed with a knowledge that i.e. importing database schemas is not fully automatic, because there is always not enough db schema information (e.g. whe migrating database from raw MySQL format to Firebird-driven Kexi project). The same for export feature: after exporting, much of project's information can dissapear. You can say it is quite like exporting e.g. KWord document to, say, RTF. Yes, but Kexi often has to offer additional dialogs to ask user for additional hints -- summing up, KO filter chains are not so usable in Kexi, since we are not performing just "convert-file-to-file" task.


!Why kexi is still a member foof KOffice suite?

* Kexi is still part of KOffice suite, what mean that from end-user perspective, strategy is the same as before. This implies that we will do our best to honour KOffice release 

* Kexi is a missing application for Free platforms like Linux, *BSD

* It (will be) still properly integrated with other KOffice compontents (KW mailmerge, KChart graphs, Kugar reports, KSpread tables ...) and/or reuse them

* Work on moving Kexi-as-KoMainWindow/KoDocument-driven application to Kexi-as-KMainWindow/KexiDB-driven application is stared by Kexi Team


%%%

Any comments and ideas and further proposals are heavily welcome :)