> > PHP5 compatibility would be good, as long as PHP4 is also supported, > > and especially is register_globals could be set to off :) > > Well I was thinking of temporarily forking the project so the > fork did not depend on any legacy requirements of the current > Savane. If it gets up and running to a usable state then various > parts, or all of it, could be adopted by Savane proper.
I guess creating a SVN branch would be ok. Maybe you'll need to separate the "clean-up" changes and the user interface improvements. Mathieu, what do you think? > I'd like the opportunity to really pull apart the code and put > it back together with coding practices developed in the last > year or two, like MVC (not strict but somewhat), AJAX, XHTML > and even more CSS. I'd personaly welcome a way to click fewer times (namely when browsing the project administration menus) :) A consideration to take into account though: even if the Savane 'framework' is pretty simple and somewhat limited, it is fast. Heavy frameworks with templates, generic input validation, state consistency, etc. like in the *nukes are _much_ slower and unsuitable for Gna! and Savannah - better keep the CPU for vital services such as CVS/SVN/Mail. Maybe that's not the technology but the way it is used, though. > I'm running a test version on PHP5 + MySQL5 > (Kubuntu dapper) right now so with E_ALL & ~E_NOTICE & ~E_STRICT > it's running okay. E_ALL produces a LOT of warnings so perhaps > eliminating them may be useful to Savane proper ? Indeed. > > Mathieu is usually hostile to JavaScript ;) but as long as you do not > > _require_ JavaScript, there is no problem. > > It's not really possible to have an AJAX interface that does > not require javascript. Savane, as is, already exists for > anyone who cannot tolerate javascript. I'm the opposite as > I've been so spoilt by AJAX that I can't tolerate web interfaces > that are not highly AJAXed. (I use AJAX and JavaScript interchangeably, that's just a matter of buzzwords ;)) I mean that it's possible to have a AJAX-enabled interface as well as a basic "vanilla-html" one, so that people without AJAX still can access Savane. Link that to the issues about accessibility, user preferences, any-browser campains, etc. > > As far as I'm concerned I'm planning new backend features (hooks > > management) > > Such as ? Such as hooks management ;) For a start, an interface to configure per-project commit notifications. > > but I may help with register_globals clean-up. > > There are 731 instances of GLOBALS[] though :-) No I mean the php.ini "register_globals" parameter, which needs to be on at the moment. That parameter automatically creates variables according to the parameters instead of using _GET and _POST. It's more secure to have it off. (SourceForge was started in PHP3 and at the time this good practice was not in use yet :/) > I'd be interested in porting all the backend scripts to PHP > too, but I have no idea what that involves yet. Is there a reason why everything should be PHP with you? ;) > PHP5 picked up one bug so far... line 33 in include/graphs.php > was "break;" instead of "return;". Hmm, afaics php4 doesn't accept that either. Did you find this error when using Savane or did you run a php5 verifier on the files? -- Sylvain _______________________________________________ Savane-help mailing list [email protected] https://mail.gna.org/listinfo/savane-help
