Hi,
On Wed, Apr 11, 2001 at 08:53:43PM +0200, Rodrigo Moya wrote:
> Hi!
>
> It seems that GNOME-DB is the only candidate for database stuff, so we
> should take special attention to this, since this would be a major use
> of GNOME-DB. One thing that's been said is that GNOME-DB should provide
> the personal database stuff to GO. By personal, I suppose it's meant
> "oriented to simple users".
Well, what i experience most from "simple users" is, that they want something
to work, but don't really care how it works. :-)
Hence, the idea with a set up default gda-provider is very good. I'm though
not sure, wether to use xml, csv, or berkeley db for that. Here are the
pros and cons having in mind, that it's for simple users.
xml:
+ independent data format -> exchangable to any architecture
+ in human readable format
- high developement effort (parser will be complex)
- can be modified by user -> possible data corruption
-> possible application crashes due to data
corruption
-> but also +: may be repaired by users
csv:
+ independent data format -> exchangable to any architecture
+ in human readable format
+ common format for data exchange
+ less developement effort than xml
- separators might also be in entries -> escape sequences might be needed
- can be modified by user -> possible data corruption
-> possible application crashes due to data
corruption
-> but also +: may be repaired by users
berkeley db:
+ fast, hierarchical data access
+ binary data storage will prevent most users from trying to modify the data
+ dbm-routines are provided by berkely db -> less dev-time
-> less bugs may occur
-> least developement effort
+ available on any *nix system
- not human readable -> exchange just possible between "equal" releases of
berkeley db on equal architectures
-> when an i/o error happens, all data might be lost
Having that in mind, i'd prefer berkeley db for the standard gda-provider,
because it's fast and reliable. XML would be my second choise; despite
the high developement effort it would be possible to modify and import
that sources easily into other GO-applications (as e.g. gnumeric uses xml
for storing its data) or even put them on a web page.
Predefined relations (e.g. addressbook table, video/cd collection table,
disk catalogue) would also be something that helps simple users use gnome-db
(and if it's just a hardcoded create table statement, first :-).
A simplified DB-Designer Component (table designer being able to add/remove
columns and finally proceed generation of the table) would also be valuable
for them (as they would not want to design using er-models, would they ;-).
Perhaps, the predefined relations could be included into this component later
or imported and modified by the users needs.
> So, although by no means do I want to lower libgda/gnome-db power to
We could add the options "Novice user" and "Experienced user" to a preferences
menu and depending on the choise the table designer from above or a more
complex component will be launched when starting e.g. the DB-Designer.
We'd have the option to either use the same component (which produces
different menus dependent on the experience level), or write different
components for each choice (where c++ or component plugins or modularization
into CORBA objects or something similar would be a great aid to inherit the
features from a basic component to a more complex one).
I'm neiter that a gui freak :-), but i think, also integration into other
GO-applications should be started at least after gnome 2.0. I suppose, a
data import facility within gnumeric or abiword would be a great help for
exchange of data between office components. For abiword, this would be the
basics for a potential mass mailings feature, with gnumeric one had certain
reporting aids for data visualization and presentation. And evolution could
possibly also import address-books from non-LDAP sources, sharing addresses
with certain other GO-applications (and possibly even GO-candidates from
GUADEC like gfax) managed by a gda-accessed dbms.
Ciao,
Holger
Attachment:
pgpFs9YXvdUzU.pgp
Description: PGP signature