History of PreflightConcept

Differences from version 2 to 16



@@ -1,64 +1,69 @@

+{{Exterminate|
+|date=13-November-2008
+|note=Perhaps it's worth combing through this page and trying to rescue some of this information.
+}}
+
+This is a fluid document still in draft - please feel free to discuss on IRC should you have any suggestions.
+{maketoc}
+!Background
+The Preflight CVS branch is based on an [http://sourceforge.net/mailarchive/message.php?msg_id=8741546|email sent to the dev list] in 17 June, 2004. Here is an excerpt:
+^...
+1 - Preflight check of configuration, database connection, valid admin user account, valid tiki tables (eg tiki_preferences) and other checks that without TP wouldn't run properly. At the moment, you are whisked away to install/install.php where the admin account passwd is ignored and the install is a little rough, overwriting existing admin info and allowing complete initialisation of the database.
+
+2 - Considering you still need a templating and formatting framework, I began wondering if the base class should actually not be TikiDB.php but something else (TikiSystem maybe?). TP classes are all inherited from TikiDB - meaning it needs to be working with a valid DB connection before you get anywhere. As much as it would prove useless, I believe that if our base class should do basic formatting, themeing, templating, etc - and DB connections should be secondary to this. This would allow the install to be better integrated into the kernel and in theory be more stable.
+...^
+
+Preflight will not be a release, seperate installer or anything like that. Preflight is basically a method to reduce our kernel to the lowest common denominator or functions and classes, to enable basic bitweaver functionality. This should, in theory, provide a more stable and streamlined kernel to be merged back into ReleaseOne.
+
+!Introduction
 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 ''preflight'' core would consist of __kernel/, lang/, themes/__ and __util/__.
+
+__The initial objective is to present an empty page with no database connection, no users but a selection of languages and themes via the modules.__
+
+The reason for this - 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 and provide and even more stable kernel for bitweaver. If we can present smarty templates, in different languages, different themes, default preferences, no database, no users - we will have a rock solid foundation to build ReleaseOne upon.
+
+I have suggested we move AdoDB and Smarty to utils/, as they are 3rd party code and libraries and should be kept seperately for updating seperately.
+
+!The Future
+This is the future of bitweaver (as I see it anyway). If you have ideas for fundamental changes, this is the place to raise them, and submit if majority agrees.
+
+Visit [http://www.bitweaver.org/forums/viewforum.php?f=10|the forum] and have your say.
+
+!Preflight Sequence of Initialisation
+Packages should be able to register check required for them to work for any of the items below. Registered checks for package version dependencies, etc should be utilised.
+
+!!System Requirements Check
+!!!Preflight library functions
+!!!Writable temp and storage directories
+!!!PHP.INI settings
+The code here should __ini_get__ settings and compare with recommended values. If they do not meet recommended values, either (to be decided) set dynamically or advise to change in the PHP.INI file.
+!!!PHP Libraries
+Check to see if suitable libraries and versions are available, such as GD, ImageMagick, LDAP, MySQL, PgSQL - possible even AdoDB and Smarty (I've noticed FC2 now comes with an AdoDB rpm).
+!!!Compatibility Functions
+The PHPCompat library could be used for older versions of PHP to allow functionality with checks for function existence.
+!!!AdoDB, Smarty and other required 3rd party libraries
+Rather than hardcode includes, we should use the library path to find these libraries. This will allow system wide references to a single library install.
+
+!!Install checks
+Check for essential packages such as kernel, users, themes, langs and util. Possibly include package version checking.
+Check for suitable libraries (under /util/) and versioning.
+Check for temp folder r/w access (templates_c, cache).
+
+!!Administrator User
+Is an admin set? Do we need to use admin password to continue installation.
+!!!Database Connection
+Using TikiDB, check for valid database settings/URI and connection.
+The installer and preflight will probably have to do different types of checks - at least during the first install. Perhaps the checks on revisiting the installer can be the same, i.e. if the file config_inc.php is already present.
+!!!Database Tables
+Check if core database tables exists, such as users_users (for admin account), tiki_preferences (for preferences), etc.
+
+!!Initialisation settings
+Check if important things are set, such as storage path.
 
-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.
+!!Package selection
+What packages are installed / are they working? can we check that? is it worth checking?
 
-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
Page History
Date/CommentUserIPVersion
13 Nov 2008 (18:27 UTC)
xing62.47.245.7116
Current • Source
Stephan Borg218.214.1.11315
View • Compare • Difference • Source
Stephan Borg218.214.1.11314
View • Compare • Difference • Source
Stephan Borg218.214.1.11313
View • Compare • Difference • Source
Stephan Borg218.214.1.11312
View • Compare • Difference • Source
Stephan Borg218.214.1.11311
View • Compare • Difference • Source
Stephan Borg218.214.1.11310
View • Compare • Difference • Source
Stephan Borg218.214.1.1139
View • Compare • Difference • Source
Stephan Borg218.214.1.1138
View • Compare • Difference • Source
Stephan Borg218.214.1.1137
View • Compare • Difference • Source
Stephan Borg218.214.1.1136
View • Compare • Difference • Source
Stephan Borg218.214.1.1135
View • Compare • Difference • Source
Stephan Borg218.214.1.1134
View • Compare • Difference • Source
Stephan Borg218.214.1.1133
View • Compare • Difference • Source
Stephan Borg218.214.1.1132
View • Compare • Difference • Source