[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]