Re: Re: cvs: php4 / TODO-4.1.txt

> >If we were to write it in C we would most likely need to provide a > >statically linked binary anyway for the different platforms as not > >everyone will have access to a fully functioning development environment. > > If they are compiling PHP and PHP extensions we can expect them to be able > to compile an ANSI C program. Which means they can also compile a simple PHP instance since we bundle xml. > >Despite the pervasiveness of Perl, chances are high that certain Perl > >modules would be missing and then someone has to go looking for Perl > >modules to install PHP packages.. Ouch! > > You can do this kind of stuff with the Vanilla Perl and don't need extensions. Doing this sort of thing non-XML doesn't make much sense to me. It severely limits the flexibility. I suppose we could have a stripped down simple format and also an XML source to keep it really simple and help bootstrap people. To start from absolute scratch I can see grabbing a shell script initially. lynx -source http://pear.php.net/go | sh Or simply download the script and run it if the system doesn't have lynx. This shell script would then determine which OS it is on and figure out how to procede. If it sees a PHP binary with XML support, it can use that. If it doesn't, it can grab a simple one for that platform. Or it kick into Perl if the Perl setup has XML support. We could also make the XML simple enough and bundle a little parser in either Perl or PHP that was smart enough to parse it. That way we wouldn't depend on external XML support. I just think it is a mistake to come up with some proprietary package description format here. The packages themselves can just be compressed tarballs, but the information about each package should be accessible via XML somehow. That virtually guarantees a slew of frontend clients almost instantly as everyone knows how to handle XML data sources these days. -Rasmus