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 <la...@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>
