CLI and parms in DB ( WAS: Re: self-intro: Craig Sebenik)

[Max Kanat-Alexander]

On Sun, 20 Jul 2008 23:29:25 -0700 Craig <craig5 at pobox.com> wrote:
> Ok, so it's not "CLI" per se that you object to, it's supporting more 
> complexity in the code. As I mentioned, *I* need a CLI so that I can 
> automate all of the administrative changes. But, I have no
> requirement for how its done. It seems to me that a CLI that utilizes
> the XML-RPC layer would meet everyone's needs. Correct?

	Sure. Or actually, if you want to develop and have a CLI as an
addon, I'd be happy to accept the functionality that you need for a CLI
in Bugzilla, provided that it's in the direction of a generally-useful
API.

> Ok, that's resonable. The simple fact is that right now, you have to 
> back up 2 different "things" for the bugzilla app: the database and
> the filesystem. The data in the DB is far more critical than the
> stuff in the filesystem. Granted losing the FS would mean any
> customizations would be lost. One problem at a time. :)

	True. However, there are some params that would likely always
have to live outside the database. I'm pretty sure that utf8 is one of
those params, since we have to know it before we connect to the DB.

> I have no idea how it would affect performance though. After looking 
> around it looks like the apps need access to do some auth checking
> (as an exmaple). Which obviously means there needs to be a call into
> the DB relatively early, like maybe during "Bugzilla.pm"
> initialization???

	Yes, that brings up another problem, is working it all out in
checksetup for the dependencies on what can happen when.

	But performance isn't an issue, we'd just read all the params
every page call and cache them.

> I really think this is worthwhile to explore... but, it may turn out
> to be difficult to do. Or, at the very least, it could mean making a
> LOT fo changes...

	Yeah, worthwhile to explore, definitely, as long as it can be
done incrementally somehow.

> Can you better define what you would like where? I realize that isn't 
> necessarily an easy question, but if we have *some* definition of
> where to put what logic, it would be easier to start making changes.

	Well, think of it in the standard OO sense of
objects--accessors & mutators and all that. Manipulation of the
accessors and mutators should generally be in the scripts (the
controller), but the mutators and so forth should be in the objects.

	In particular, I'd like to avoid having any SQL whatsoever in
the controllers.

	-Max