[prev in list] [next in list] [prev in thread] [next in thread]
List: koffice
Subject: Re: Introducing: Kbase
From: weis () stud ! uni-frankfurt ! de
Date: 1999-04-27 19:56:56
[Download RAW message or body]
Hi,
Sounds very interesting!
I am looking forward to it.
Bye
Torben
On Mon, 26 Apr 1999, Jim McCusker wrote:
> Do you think that Koffice development isn't spread thin enough? Do you
> want to work on the next best thing since timesliced bread? Ever wanted to
> try your hand at a 500 piece CORBA/KOM puzzle?
>
> If so, then Kbase is for you! Come help myself, Michael Koch, and Peenak
> Inamdar futilely hack at a project so froody that you won't know where
> your towel went. :-)
>
> What is Kbase? Breifly, it's a desktop database application not unlike
> Paradox and Access. But it's so much more!
>
> Here's my idea for Kbase:
>
> The main body of Kbase is that of a plugin framework. Each part of the
> database is a KOM application that plugs into a base manager.
> We will have (to start):
>
> o Kdataparse:
>
> This is, in itself, a place to plug in a means to access various data
> formats. There'll be one for the std database, and one for each supported
> data type, including the interfaces for connecting to SQL servers.
>
> Kdataparse will show the same interface to the programmer no matter what
> the database type is. This makes it easy to move back-end implementations
> with minimal pain and suffering should a database need to be upsized.
>
> What you would give Kdataparse would be an SQL statement that describes
> the data requested, no matter what format it's in. (As long as it's
> accessable from the open database) This will include both tables and
> queries, as well as the ability to ask for a live dataset, a snapshot
> dataset(read only), or a live dataset (read only). What it returns is a
> data structure (or whatever CORBA gives back) that is the interface to
> that particular table/query.
>
> Also, Kdataparse the views necessary to work directly with tables and
> queries (editing the structure, editing the data, etc.). Kdataparse will
> also hold the code for relationships, referential integrity, etc.
>
> At some point, I'd like to make an XML-based database format, and have
> that be the default format (pipedream)
>
> o Kforms:
>
> This will be something that generates and displays forms. We can hack
> something from the xml-based form-maker for QT or KDE (is that still
> around?). It is important that we don't have a one-to-one relationship
> between forms and tables/queries. That is, forms don't have to be linked
> to any forms/queries, and you can have more than one form per table/query.
> Kforms can also hold a sql statement as a control source, rather than just
> a saved query or table.
>
> o Kreports:
>
> This will use an XML/XSL format for making reports. The XML will be the
> resulting data that is spit into an XSL template, which is the actual
> report that will be output. We can use konquerer (maybe put in XML/XSL
> support?) for the print/display engine.
>
> o Kscript:
>
> This should be done through the python interface and all. We can extend it
> (and probably use it throughout Koffice) so that it includes an editing
> environment that is friendly, like syntax highlighting, object/function
> browsers, etc.
>
> The overall structure would look like this:
>
> Kbase
> |-> Kdataparse
> ||-> Ktable FE
> ||-> Kquery FE (based on Ktable)
> |\-> actual interfaces to database types
> |-> Kforms
> |-> Kreports
> |-> Kscript
> \-> whatever else we think of.
>
> I'm figuring that, in the future, more people, not just koffice
> developers, will contribute different plugins to this architecture. Future
> work would include data mining, connecting reporting up to a future
> mod_koffice (for apache publishing and the DOM stuff), creating a sql
> server out of the Kdataparse plugin (this should be easy, since it already
> will use corba), adding more languages that are usable, whatever is
> thought of. And they would be installable at runtime, possibly as needed.
> Of course, any of these pieces can be plugged into any of the other
> Koffice apps. I know that Kspread would kick some real arse with actual
> database embedding (Excel just has a slow MS-Query interface or even
> crappier native database functions).
>
> If you want to help out, or have any more ideas for the project, you can
> post here, or mail us:
>
> Peenak <pinamdar@cs.rochester.edu> will be in charge of the database
> engine work. He's currently studying hard on some database theory stuff.
> Contact him if you're interested in working on engine stuff.
>
> Michael <m_koch@bigfoot.de> will be working on the front-end GUI stuff.
> Contact him if you are a graphics-type or a UI/ human-factors type, or if
> you are a QT whiz.
>
> Jim (me) <mccusker@iname.com> will be working on, for now, just about
> everything else. I've got some studying to do on CORBA/KOM/OpenParts. I'll
> also probably be working on the logic for the rest of the system,
> basically batting cleanup. If you're interesting in the rest of the
> system, come talk to me.
>
> Thank you for your time,
> Jim
> ===
> Jim McCusker | mccusker@iname.com
> http://cif.rochester.edu/~fprefect
> Wax I in your general direction! Your mother was a hamster,
> and your odors of father of elderberries! Go now far, or I
> taunt you second once, you them English pig-dogs!
> --Monty Python through babelfish.altavista.com
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic