Re: Houston, we DON'T have a problem...

[Aaron Turner <aturner@linuxkb.org>]

On Mon, 3 Jan 2000, Jason Pincin wrote:

> > I know you've got big plans later on for the KB engine, but I think we
> > need to worry about the KB first and bigger plans later.  We need to worry
> > about the needs of our environment right now and that of other uses later
> > on (like after go live ;-)
> 
> I COMPLETELY understand what you're saying here, and I understand your
> concerns for me thinking future as well as present when designing the
> KB frame work.  It's a good way to get ahead of myself and slow things
> down.
> 
> But you need'nt worry.  I'm running out of time to get all this
> done... I'm under some pressure from our sponsers as well, and am

Well then at least I'm not the only one.  :-)  Note to everyone else who
hasn't had the pleasure of working with our sponsors:  They're all very
nice and ask on a regular basis "When are you going live?".  For the last
year I tell them: "I don't know, but I'd be happy to lie to you if you'd
like."

> doing things by judging "time to readiness"/"How I think it should be
> done"/"functionality" ratios.  The way it is implimented now servers
> many things very well, and I have sunk a great deal of time into a
> multitude of functions and inter-operating pices that rely on the
> present structure. To change it now would cost more valuble time in
> which we would simply be re-engineering - not approaching our goal.  
> The results of the re-engineering, to me, don't warrant the lost time.

Fair enough.  I understand that changing things now would slow things
down, but it means we need to build some tools to facilitate moving
categories around.  My guess is that the PHP objects won't take care of
all the necessary work for this to be possible, so it's going to take some
underlying SQL.  I'm willing to give it a try in Perl just because I'm the
freak that is asking for it and because I've almost finished the man2html
cgi to modperl port.

> I suggest we roll with what we have, and let me propose a way to work
> around the re-organization problem with our current solution rather
> than re-engineering the backend to better suit re-orgaization.
> 
> > What does "assessig the impat on the DB" mean?  What impact?  The DB
> > performance?  Editing your PHP objects?
> 
> Well yeah... every change we make to the backend or php objects is
> going to produce different loads on the DB.  I understand we can
> always add more hardware, but if we can keep the DB in line with some
> intelligent methods of accessing data, why not?

That's a good point.  I don't want us to need one of those 8way Xeons for
our DB server.  At the same time, we need to remember our biggest problem
isn't that we're getting hammered right now- rather the opposite.  Hence,
making it work is #1 priority.  (I know Jason agrees with this, just a
friendly reminder to everyone else out there who is trying to make their
code "perfect".)
 
> > Anyways, I don't wan't this issue to delay our go live in Jan, but I
> think > we need to address this issue before we get too much content
> in the DB or > we're going to end up making our lives harder later on.
> 
> Well, lemme know what you think of the above.  I'll be on-line all day
> tomorrow.

--
Aaron Turner, Core Developer       http://vodka.linuxkb.org/~aturner/
Linux Knowledge Base Organization  http://linuxkb.org/
Because world domination requires quality open documentation.
aka: aturner@vicinity.com, aturner@pobox.com, ion_beam_head@ashtech.net
The difference between `Unstable' and `Usable' is only two characters: NT