Re: Houston, we have a problem...

[Aaron Turner <aturner@linuxkb.org>]

On Thu, 30 Dec 1999, Jason Pincin wrote:

> > > I figured, permissions scans would be happening on nearly every page load,
> > > and re-organization's would be once-and-done type queries... so I opted
> > > for the approach you see before you.
> > I don't see why.  There's no need to do a permission scan for avg. joe
> > user who is using the site.  Only category admins.
> 
> Because I'm thinking broader than just the KB.  Sure, in ouir enviroment,
> most people will have "read" perms over everything... but I'm trying to
> design this system so that it will eventually scale to other applications
> as well.  In other apps, it may be necisary to check perms on
> everything... and if it's done quickly, it doesn't impact us anyway...
> and, it's already implimented so... if we go this way, we are targeting
> other apps, it works for us, and we don't change anything.

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 ;-)
 
> > > This will be a total pain in the ass to re-organize at the sql cmd-line
> > > level, but the admin pages can handle it very easily.
> > Are you say converting to my proposal will be difficult?  It would be VERY
> > easy to do in Perl.  Maybe 20 lines of code, max.
> 
> No.  It wouldn't be overly difficult to make the modifications.  Assessing
> the impact on the DB would be a different story.  I don't like the idea of

What does "assessig the impat on the DB" mean?  What impact?  The DB
performance?  Editing your PHP objects?

> updating a permissions table of file 6 times a day like we're doing with
> PHP Cache... permissions must be real time.

Why?  What are we protecting?  Knowledge about an open source OS.  Unless
we're talking protecting nuclear secrets, who cares?  Make it once a
minute if you like.  That should be good enough for most cases.

That or faster hardware.  Many problems are solved with faster hardware.
:-)

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.

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