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

List:       kde-devel
Subject:    Re: Kash Kontinued.
From:       Stephan Kahnt <stephan.kahnt () ipk ! fhg ! de>
Date:       1999-11-03 13:27:59
[Download RAW message or body]

> 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 :-)

Hi,

you say SE and OpenSource are totally different, but do you think they
are really contradictory? I think most of programmers don't know a lot
about SE. So they just start to code with a vague image of the structure
in mind. Nowadays there are powerfull tool (e.g. cvs) to support such a
proceeding. But isn't it much easyer to discuss the design in a mailing
list and have thus a kind of SE. I aggree, there is a danger of
overplaning. I suggest a compromise e.g. a time table to plan the
necessary steps. When it's time according to the time table, we could
start coding. I'd like to try it this way.

Stephan

-- 
----------------------------------------------------------------------
Stephan Kahnt
TU Berlin	Tel : ++49 30 39006-241
REMOVE NOSPAM	mail: stephan.kahnt@ipk.fhgNOSPAM.de
----------------------------------------------------------------------

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