Re: [PHP-GTK] Status of PHP-GTK

Maybe this will sound like blasphemy, but wouldn't it be more reasonable to 
ignore the far-fetched multiformat, docbook, php.net-integrated, approach 
and go for something more lightweight that would be completely (X)HTML-based 
using a CMS in massive use (you know which one I'd recommend) ?

Is it better to have a "clean", enterprise-type, XML-centric process 
yielding only PDFs over 1 year old which only specialists can build anyway 
when the system is broken, or to have something which is mostly web-centric, 
with an easy content redaction UI, and is constantly alive, using a CMS site 
technology which over 100k people know how to run/maintain, with serious 
community interaction features being maintained by the CMS community instead 
of the PHP-GTK devs who are already swamped in work and have more important 
things to do regarding PHP-GTK than working on a web site ?

I'll gladly admit that it would obviously hit harder on the server resources 
because such frameworks are inherently heavier, but is it really a problem 
considering the actual frequentation ?

Of course, this doesn't come out of the blue: I've been suggesting this 
approach more or less since late 2007, and its initial rejection was what 
led me to create php-gtk.eu, so that the lost wiki pages and apps repository 
from gtk.php.net would be available again.

And in case this isn't perfectly clear, should this turn be taken, I'd 
gladly take part in the migration process, just like I did for the wiki and 
apps sections. And several community members already use this same CMS for 
their own sites, so I wouldn't be the only one knowing it.

Frederic

----- Original Message ----- 
From: "Steph" <[email protected]>
To: "Andre Colomb" <[email protected]>
Cc: <[email protected]>
Sent: Thursday, April 16, 2009 11:08 AM
Subject: Re: [PHP-GTK] Status of PHP-GTK



> Concerning the state of the manual: What would it take to fix the build
> system? It worked at one time, but all I hear is that it needs to be
> updated to DocBook V5. Whoever broke it should just fix the damn thing
> so the old DocBook V3 sources can still be maintained.

Agreed 100%. Last build December 2007 - what happened in December 2007 that 
made it stop working?

After all, it is
> in a VCS where one can go back in time, right? I don't see a realistic
> chance that anybody will step up and rewrite the whole manual just for
> fun. Besides, there is still the problem with OOP support in DocBook I
> presume?

Yep. Although DocBook version 5 was supposed to address that problem, the 
approach hasn't been quite what we might have hoped, in that it isn't a good 
match for PHP-GTK's needs. (I did look at it, just my heart sank when I 
did.)

> I know I'm only saying what "should be done". If there was an easy way,
> I'd gladly help with the documentation. Until then, I'll just try to
> post whatever problems (and solutions) I come across to the ML and other
> public places. Unfortunately I don't have the time to work on the big
> problems, so this is my way to contribute.
>
> All developers, keep up the nice work even if it's in the shadows to the
> common subscriber :-)
>
> Regards, Andre

-- 
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php