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

List:       kde-devel
Subject:    Re: Kash Kontinued.
From:       "Michael J. Bedy" <mjbedy () mtu ! edu>
Date:       1999-10-31 3:48:45
[Download RAW message or body]


   I'm starting to think that I may be thinking about this the wrong way.

   I know very little about databases, so could someone who does answer me
this:

   Does there exist a free database system, suitable for a program of
this type, that can work on a file in the users home directory?

   The reason i ask is that people keep recommending stuff like ODBC and
SQL, while my impression was that these are very heavy weight things that
require a large amount of setup. Can somthing like MySQL or postgres be
told, easily, that I want them to access ~/.kdekash/database.db?

   I know gdbm exists for small scale databases, SQL is good for large
scale - is there an existing "medium scale" database that we can use. If
there is, then I think the typical open source "start coding and see what
happens" method of doing things may well be the best. The only part I am
nervous about is the database.

   Is there anybody out there that knows a lot about databases that would
be interested in working on this project? Truth be told, I am probably not
the best person to be thinking about stuff like that. I don't have any
experiance. GUI and application stuff I could be a LOT more confident
about. (Well, my graduate research is in compilers, but i don't think that
applies here :-)

     - Mike


On Sun, 31 Oct 1999, Corrin Lakeland wrote:

> Hi, I'm sending this to you directly because kde-devel doesn't like my From:
> field.
> 
> >>[Use a database]
> >  
> >    I agree. But I envision an abstraction that allows for a number of
> > different implementations. There would be an interface that rest of the
> > program could talk to, and each storage type would implement the required
> > features. 
> 
> Reading this,  ODBC sprang into mind and started flashing with lots of bells
> ringing around it...
> 
> >    Also, it may be that the user wants a number of databases open
> > simultaniously (credit card, checking, etc.) and a way of organizeing this
> > is necessary.
> 
> No.  A user might want access to many TABLES, but they really should only need
> one database.
> 
> >    AND more than one part of the program may want to access the same
> > information at once (regeister is open, yet the report wants to read the
> > data also.) Coordinating this requires some thinking as well.
> 
> Not really, Databases are very good at concurrency -- just have a look at
> something like Date to see how much effort they go to.  Just as long as you
> don't keep pointers yourself, it isn't every hard.
> 
> >    BUT WAIT THERES MORE! The database layer should be as secure as
> > possible. This is probably a storage method specific problem, but we need
> > as part of our interface an abstraction for dealing with
> > encription/password type stuff.
> 
> Hmmm, hmmmmmm.... Nah, just leave it all to the database.  Databases have
> concentrated on security for a long time now, they're much better at it than
> you're ever going to be.  Provided you never go behind their back, their
> security model is going to be bulletproof.  Really, the only thing you have to
> be careful about is that the passwords for accessing the DB are dealt with
> carefully (umask 377 on the config file).  The database will ensure the user
> only gets access to what they are supposed to access.  Just don't try the
> equivilant of suid too often and you won't have any trouble.
> 
> Like most people on this list, my interest increased significantly when you
> said you'd treat it as a SE project.  I've both taught SE and participated in
> OpenSource development projects and I think the models are totally different,
> though I'm looking forward to being proved wrong.
> 
> SE believes in designing things correctly, building an implementation of that
> design (called a prototype), and building a new design to fix whatever things
> weren't liked about the prototype.  A lot of thought goes into design so that
> you don't code something 'wrong'.  However, SE is aware that other approaches
> exist, and even includes the model used by open source, under the label spiral
> model.  
> 
> I really don't think any other model works for nontrivial open source
> applications; design flaws WILL be present in version one, but the rewrite you
> have to do for version two will get rid of them.  Reliability comes from
> extensive reuse (80%?) and the code is studied by so many people, not from
> careful planning.  Design flaws are also minimised by the philosophy of doing
> each part well rather than rushing to get a complete product to market.  Have
> you read the cathedral and the bazaar?
> 
> Still, as I said above, I'm looking forward to being proven wrong :-)
> 
> Corrin Lakeland
> --
> Corrin Lakeland <lakeland@cs.otago.ac.nz>             Phone 64 6 876 5219
> Department of Computer Science                Faculty of Business Studies
> University of Otago, New Zealand      Eastern Institute of Technology, NZ
> 

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