Re: PHPseclib/PEAR packages

I try to keep PEAR's Math_BigInteger in sync with phpseclib's
Math_BigInteger but the reality is PEAR is just much more easily
overlooked as most support requests come in through phpseclib.  As
such, I'd be up for superceeding PEAR's copy.

phpseclib/PHP_Compat is pretty much a stripped down copy of PEARs.
Rather then include the whole PHP_Compat library - most of which isn't
needed - I just included what is needed.

As for PEAR's Net_SSH2 vs. phpseclib's Net_SSH2...  personally, I'd
say phpseclib's Net_SSH2 is better, but I'm not exactly an impartial
individual lol.  PEAR's Net_SSH2 requires either proc_open be
available for use or the libssh2 extension be installed.  Because it's
done in pure PHP it pretty much has zero server requirements and it
makes for a much more intuitive API in my opinion.  PEAR's Net_SSH2 is
constrained by the CLI interface and the libssh2 interface.
sshKeyGen() in phpseclib is done with the Crypt_RSA() object,
sshCopyId(), in my opinion, doesn't really belong, and scpSend() /
scpReceive()...  phpseclib has a whole Net_SFTP class to do that and
more.  phpseclib supports "interactive" mode (ie. expect) and logging
too.  And despite being done in pure PHP it's usually faster than
libssh2 too.

Finally, I'm down for switching to github.  It's not something I'd do
overnight but I have been using git a bit at work and have gotten
decent enough at it.

On Mon, Dec 5, 2011 at 4:30 PM, Daniel O'Connor
<[email protected]> wrote:
> Hey Jim,
> There's a few PEAR packages and PHPseclib packages, some of which you
> maintain, where there's source in two places.
>
> What's your thoughts on perhaps:
>
> Superceeding http://pear.php.net/package/Math_BigInteger/ for
> phpseclib/Math_BigInteger (or whichever one is more maintained)
> Merging phpseclib/PHP_Compat with pear's PHP_Compat, or renaming
> Picking whichever one of http://pear.php.net/package/Net_SSH2 is better
> etc
>
> ?
> And or swapping to github?
>
> Previously, we've been keen to get everything in the PEAR svn repo; so that
> QA changes can be applied if needed. However, now that github has arrived;
> it's trivial to fork a repository and apply fixes - so the need for it to
> "all be in PEAR" is far less if we're using github.
>
>