[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Article about OOo/KOffice/OASIS database
From:       "M. Fioretti" <mfioretti () mclink ! it>
Date:       2004-07-15 16:44:41
Message-ID: 20040715164440.GA957 () mclink ! it
[Download RAW message or body]

On Wed, Jul 14, 2004 10:05:14 AM +0200, Frank Schönheit

> - either Kexi or OOo DBA would have to change the file format itself
>   (package based vs. SQLite based on the top level)
> - Kexi and OOo DBA would need to agree on a common format for describing
>   queries (which shouldn't be *too* difficult)
> - Kexi and OOo DBA would need to agree on, and implement, a common form
>   model and format. Currently OOo DBA uses OOo Writer documents (plus a
>   form layer) as forms, while Kexi seems to have an own
>   implementation.

Frank,

I'll let KOffice developers answer to your other comments, but would
like to say something, about the last point above.

If I (generic end user, not interested in SW internals, just to be
Free of proprietary SW and formats) hear at every corner of the Net
that:

1) The OO.o format has become an open  standard of its own through
   OASIS
2) KOffice, another complete office suite, has decided to make the
   OASIS standard its own native format
3) Kexi is part of KOffice

then I'll conclude that there is *nothing* at all to still agree on,
as far as forms are concerned. The 3 points above would mean to me
that a choice has already been done (even if not all the interested
parts have realized it yet): forms *will* be OASIS text documents,
hence directly useable both in KOffice, OO.o and whatever comes
next. Which is all an end user cares about, documents and data being
fully useable with different programs.

Now, this message will probably generate a lot of answers pointing out
that things are not so simple, that there is this or that other
technical problem to solve, that it will take at least X months/years,
or that you just don't like the idea or don't feel like coding it.

OK, no problem, really. I accept all such objections, and the
corresponding estimates, in advance. I trust your programming skills,
and am certainly not trying to force anybody to code for free,
tonight, what *I* think right.

The main thing I'm interested into is to figure out how complex the
problem is, and above all *if* there is in KOffice/OO.o the explicite
will to fully converge on this. If yes, that's what matters, and if it
takes (just making up numbers!!!!) one year instead of one day is not
a real problem.

Thanks again for your time,

	     Marco Fioretti

-- 
Marco Fioretti                    mfioretti, at the server mclink.it
Red Hat & Fedora for low memory   http://www.rule-project.org/

Computers are useless. They can only give you answers. -- Pablo
Picasso 
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]