So, here's what I've got in my head...

We checkout kernel/, lang/, themes/ and util/, and we delete all the code in kernel that has to do with other packages. The objective is to present an empty page with no database connection, no users but a selection of languages and themes via modules.

The point being - the first page of the install could be used to select a language (and maybe a theme), without necessarily having a db connection, preferences or users for that matter.

If we can build the kernel to support these functions, without a database or users, it would be perfect for the installer - so if we can present smarty templates, in different langs, different themes, default preferences, no database, no users - we will have a rock solid foundation to build clyde upon.

---

TODO
<wolffy> utils/ would be the other directory we need to check out
<wolffy> I suggested to spider we move adodb and smarty to utils/ as they are 3rd party code and should be kept seperately
<xing> i have been thinking the same for a while.
<wolffy> great minds...
<xing> it's a strange place to keep smarty and adobd
<wolffy> all 3rd party libraries should go somewhere common - that way we know they are seperate and it also allows someone who has them installed somewhere else not to worry about that package
<wolffy> you don't like it?
<xing> i lik eit
<xing> i like it
<wolffy> so thats pretty much it - I've got clyde checked out here - and I could start stripping stuff, but I'm not sure how I'd get to check it in
<xing> perhaps we should branch your testing grounds sepertately
<xing> we could give it a new head until it's done and then merge
<xing> a new branch rather
<wolffy> yeah - true
<wolffy> I guess it doesn't effect everybody if we do it that way too
<wolffy> which is a good thing
<xing> so, we should have a new branch called something like preflight and include only _p_tp_kernel, utils, lang, users, what else?
<wolffy> no, thats about it
<wolffy> preflight - I like it
<wolffy> making a branch now
<xing> so, can we do that, or do we need spiderr to do that... just saw your answer
<wolffy> I have to go to bed soon - big day tomorrow
<wolffy> but I'll finish this first
<wolffy> probably won't be able to sleep cause I'll keep thinking about it :)
<xing> :)
<xing> what do think of this menu? it's free. don't know if it's compatible with out menu system but i'll have a look. phplayers is such a pain and it's so big as well
<xing> http://www.aveda.com/home.asp
<H0ney> Title: It's a great day at AVEDA (at www.aveda.com)
<wolffy> its not perfect under mozilla, but it looks good
<wolffy> is that javascript?
<xing> yes
<wolffy> CVS index.php languages temp tiki_setup_inc.php doc kernel robots.txt themes util
<wolffy> thats what we've got
<xing> do we need users?
<wolffy> no initially
<wolffy> not initially
<xing> ok.
<wolffy> I'm think we hard code an admin user as fallback during an install
<xing> what is the tag and branch?
<wolffy> its PREFLIGHT - but its not ready yet
<xing> ok
<wolffy> just testing it
<CIA-5> wolff_borg * CVSROOT/modules: Added tagged and added Preflight
<xing> tell me when you're ready for me to check it out
<-- xing (xing@62-99-189-130.static.adsl-line.inode.at) has left #tikipro
--> xing (xing@62-99-189-130.static.adsl-line.inode.at) has joined #tikipro
<xing> sorry about that
<wolffy> cvs -qz5 -d :ext:wolff_borg@cvs.sf.net:/cvsroot/tikipro co -r PREFLIGHT -dpreflight preflight
<wolffy> obviously use your account - this will create a directory called preflight
<wolffy> I should probably document this somewhere for the public

• xing is getting it

<xing> i hope i picked the right stuff:
<xing> -r PREFLIGHT -d preflight
<wolffy> -dpreflight preflight
<xing> well, it's here now