Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52487
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:cc:content-type;
        b=qf2XqvYV6XK3NtNKriDO32H0kkKI9z5PUMztUNSEffPbOwUgny5BVl9MpIoJwWP1Qr
         REvJcElMUgSr8jGid75uGiUs8gtcpS89FBIRlZnYU+B8uP3dKXe29NcK+MZAG/6H9UnV
         4rWDaDEmvrmYYacWlDnwDA9DZHj/mBlO9FjLY=
MIME-Version: 1.0
Sender: andrewcurioso@gmail.com
In-Reply-To: <4DD693BB.7030300@garfieldtech.com>
References: <4DD693BB.7030300@garfieldtech.com>
Date: Fri, 20 May 2011 12:47:18 -0400
Message-ID: <BANLkTikVasPk356z-6O_G3kGzQ3gHqPwgw@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=20cf3071ca6aef7b4e04a3b7dfcb
Subject: Re: [PHP-DEV] Porting PECL to userspace
From: andrew@andrewcurioso.com (Andrew Curioso)

--20cf3071ca6aef7b4e04a3b7dfcb
Content-Type: text/plain; charset=ISO-8859-1

AMF-PHP does something similar to this.
It is a PHP implementation of AMF (Action Message Format) so it allows you
to accept and respond to AMF messages from Flash apps.

Its native PHP encoder is extremely slow but it works. However, if you
install amfext from PECL it will use that for encoding instead.

AMF-PHP is more than just an encoder, though; whereas the extension is only
used for the encoding part.
So, in that regard, it may not be the best example to go by for what you
want to do.

- Andrew


On Fri, May 20, 2011 at 12:15 PM, Larry Garfield <larry@garfieldtech.com>wrote:

> Hi all.
>
> I'm working with a fellow developer on an experimental project.  There 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 module
> to include in the project and rely on that.  Then 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.  Poof, nice speed boost.
>
> The questions I have are:
>
> 1) Is this even a viable approach?  It seems like it, but to my knowledge
> 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?  No sense doing it ourselves if someone else
> already is.
>
> 3) What would be the cleanest way to do so?  We had the thought of
> partially automating the process by having PHP auto-generate at the very
> least the subs of any classes and functions that the module provides.
>  However, 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.  We were using the PECL HTTP module as our
> sample (http://www.php.net/http).  (I don't know the exact details of what
> he did at the moment.)  Is that not a viable approach?  Would we be better
> off using reflection?  Is 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
> goes.  I know it wouldn't work for all PECL modules, obviously, but I
> suspect it could work for several, and provide an easy way for different PHP
> projects to share backend code without needing lots of C developers.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.ph<http://www.php.net/unsub.php>

--20cf3071ca6aef7b4e04a3b7dfcb--