Re: cvs: php4 /pear/scripts pearwin.php
| From: | Vincent Blavet | Date: | Wed, 13 Feb 2002 12:32:12 +0000 |
| Subject: | Re: cvs: php4 /pear/scripts pearwin.php | ||
| References: | 1 2 | Groups: | php.pear.cvs |
| Request: | Send a blank email to pear-cvs+get-2420@lists.php.net to get a copy of this message | ||
----- Original Message -----
From: "Stig S. Bakken" <ssb@fast.no>
To: "Vincent Blavet" <vincent@blavet.net>
Cc: <pear-cvs@lists.php.net>
Sent: Wednesday, February 13, 2002 11:44 AM
Subject: Re: [PEAR-CVS] cvs: php4 /pear/scripts pearwin.php
> On Wed, 2002-02-13 at 09:50, Vincent Blavet wrote:
> > vblavet Wed Feb 13 03:50:07 2002 EDT
> >
> > Modified files:
> > /php4/pear/scripts pearwin.php
> > Log:
> > - Adding support for remote-list command (with XML-RPC installed)
> > - Start support of show-config (still work to do ...)
>
> We need to come up with a way to avoid this double effort.
I'm agree !
Today most of the command should be portable from Unix and Windows. The main
problems I see is that some defines (PEAR_INSTALL_DIR, ...) are not
correctly set on a window system.
This is not the case of the remote-list command that is the same between
Unix and Windows.
>
> I suggest making a more abstract command API (replacing the
> pearcmd-xxx.php stuff) with a factory on top. The command API should be
> generic enough to support command-line on Unix and Windows as well as
> web and Gtk installer, it has to define options that the different front
> ends map to their own format (getopt flags for the command-line, forms
> for web and dialogs for Gtk), and it has to provide simple
> documentation.
>
> Example:
>
> $command = PEAR_Command::factory("package.listAll");
> $command->setParams(true);
> $command->setOptions(array('server' => 'no.mirrors.pear.php.net'));
> $result = $command->run();
>
> or
>
> $command = PEAR_Command::factory("package.install");
> $command->setParams("HTTP_Upload");
> $result = $command->run();
>
> The factory makes it possible to use a generic class for all "remote"
> commands, and have special handler classes for commands that do a lot of
> local processing (like "install"). It will also enable us to add
> caching of package/release lists for offline use, and install files from
> mirrors or the local filesystem.
Does this will solve the problems with environment variables that seems to
be interpreted differently on different systems ?
>
> - Stig
>
>