Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52484
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:reply-to:in-reply-to:references:from:date:message-id
         :subject:to:cc:content-type:content-transfer-encoding;
        b=qYjkFnInzza3gVphWAyt+Eg2Rtp2HwKvwp36SyGxeTy22xjUQTYvLdT3mNa1ZFpOGw
         gNOP/fLAupev5vCIkigYRSqgUxOG/fE1zKfbCraNhv+HT35KVVecNYTDAAWJCWf3moPG
         nqPJluX1Fsj8oC9SuFzN3m/3zlvVrTKYmYNpE=
MIME-Version: 1.0
Reply-To: RQuadling@GMail.com
In-Reply-To: <4DD693BB.7030300@garfieldtech.com>
References: <4DD693BB.7030300@garfieldtech.com>
Date: Fri, 20 May 2011 17:34:37 +0100
Message-ID: <BANLkTinpXOkdg+wJBXjH9Lcs20R=fuqx1w@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Porting PECL to userspace
From: rquadling@gmail.com (Richard Quadling)

On 20 May 2011 17:15, Larry Garfield <larry@garfieldtech.com> wrote:
> Hi all.
>
> I'm working with a fellow developer on an experimental project. =C2=A0The=
re are
> some PECL modules that we want to try and use in an open source project
> where we cannot guarantee that PECL modules will be available, since it's
> intended for widespread distribution on both shared hosts and custom
> hosting. The thought we had was to do a user-space port of the PECL modul=
e
> to include in the project and rely on that. =C2=A0Then if the PECL module=
 is
> installed, we don't include the library (either via an extension_loaded()
> check or just relying on autoload) and the PECL implementation gets used
> instead. =C2=A0Poof, nice speed boost.
>
> The questions I have are:
>
> 1) Is this even a viable approach? =C2=A0It seems like it, but to my know=
ledge no
> one else has done this to any serious extent which makes me wonder if
> there's a reason the road less traveled is less traveled.
>
> 2) Is anyone else doing this? =C2=A0No sense doing it ourselves if someon=
e else
> already is.
>
> 3) What would be the cleanest way to do so? =C2=A0We had the thought of p=
artially
> automating the process by having PHP auto-generate at the very least the
> subs of any classes and functions that the module provides. =C2=A0However=
, when
> my colleague tried using the same parser as is used for generating
> documentation he says he got several times as many classes as the manual
> says the module has. =C2=A0We were using the PECL HTTP module as our samp=
le
> (http://www.php.net/http). =C2=A0(I don't know the exact details of what =
he did
> at the moment.) =C2=A0Is that not a viable approach? =C2=A0Would we be be=
tter off
> using reflection? =C2=A0Is there some other tool we're not aware of?
>
> If viable I'd love if this would start a trend, but we'll see where it go=
es.
> =C2=A0I know it wouldn't work for all PECL modules, obviously, but I susp=
ect it
> could work for several, and provide an easy way for different PHP project=
s
> to share backend code without needing lots of C developers.
>
> --Larry Garfield

If you using an extension that exists as glue to a third party
library, then you are going to need PHP to communicate at a very low
level. Something I'm not sure would be possible at the moment.

If the extension is self contained, then this would more likely be a
good candidate.

You can use reflection to build the stubs easily enough

But I'm not sure all the things you can do in C can be done in PHP,
not without a LOT of effort. Talking to third party libraries or
making c calls to the OS is out.

Richard.
--=20
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea