Re: [Phpwiki-talk] Ready for 1.3.8 ? Heads up

[Reini U. <ru...@x-...>]

Matthew Palmer schrieb:
> On Wed, Mar 17, 2004 at 10:18:26PM -0600, electron wrote:
>>Defines suck. Defines are everywhere where they don't need to be. Index.php
>>is hugely bloated, complex and not documented well.
> 
> Index.php shouldn't be a .php file.  PHP has a wonderful .ini parser, and
> nobody uses it!  I'd recommend doing a switch (it might not be a 1.3 series
> thing, though) to a .ini config file, out of the web tree entirely.  An
> autowriter should be easy enough - load up index.php, iterate through the
> define list, and write it all to an ini file.  Lack of internal
> documentation on that will suck, though, but a default "edit-through" ini
> file should work well.
> 
>>Finally, Documentation, Doc, and Doc!
> I *think* that most of the stuff people are interested in is documented
> inside the Wiki somewhere, but a lot of things just aren't easily
> accessible.
> 
>>There is no rush to get to 1.4.0. 1.4.0 should be a complete, pretty, easy
>>to install and easy to administer wiki miniCMS. 

Well, the "easy to install" thing is controversial.
Let's discuss a ini-style config. For all my other projects I use simple 
ini files, because they are language independent, and can be moved away 
from the project tree. (to /etc/ e.g.)

Personally I prefer like the current way, esp. for wikifarms or 
multilingual sites, like PhpWikiDemo. index.php is easy to include and 
override behind the master script, a phpwiki.ini not. Why another 
parser? Just the db and admin password exposure is problematic.
Can somebody setup a PhpWiki:IniStyleConfig page for 1.4.0?
With pro's and contra's.

> Does SF have the ability to group "tasks" into releases, for planning
> purposes?  If everything were tracked there, it would make it easier for the
> externals like me to see how things are going.
> 
>>1.3.8 Should proceed to 1.3.9 and implement a roadmap to 1.4.0.
> Erm, no.  The 1.3 series should be bugfixes only.  Even my SQLite stuff
> shouldn't really be released in a 1.3 series, unless it gets a *hell* of a
> lot of testing (which it will, shortly).

sqlite is only included as experimental backend, to attrack people to 
test it. For sure it's not a supported backend. But we have to start to 
do it.

> We need to create a new 1.4 branch to make all these developmental changes
> on. Fork from the existing 1.3 tree and start hacking.  Make those big
> changes like rewriting all the DB stuff.  Nothing in there should
> necessarily be working particularly well, although keeping as much stuff
> working as possible is good, because then the bold people can run it for
> kicks.  But 1.3 is not the place to be working towards 1.4, because then we
> either have no really new innovations in 1.4 (because we had to keep all the
> old crud working), or nothing works for a while in 1.3 (because things are
> being broken all the time and not everything is stable at the exact same
> time) or we don't make any releases (because nothing's working properly).

1.3.8 is basically a test release for 1.4.0 with enforced page 
permissions (this is the real major change), the new auth and pref 
layout, paging support and some DB enhancements.

The new DB enhancements are no big rewrite, just an minor update from 
the ADODB mainline, to support all other databases with adodb also,
nuke integration, and esp. to make use of the php_adodb.(so|dll), so we 
need the ADODB classes instead of the functions.
In fact it's more like a necessary ADODB cleanup.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/