Extension development for hiphop servers

[Karmac Coding]

Can someone tell me what is involved in bringing over existing
extensions into the hip hop environment? If I have a compiled php
extension, is there any way to use it in hphp or hphpi? I saw some
things in the doc, but it was awfully vague and didn't really cover
existing extensions.

[Karmac Coding]

Judging by the deafening silence in this thread, I take it no one has
any experience working with extensions in hiphop? Or is this group
just not very active? So far, only a few people out of close to 1800
people have posted anything in the last week. I was under the
impression that this was open sourced so that a community could get
involved, but it looks like there's not much conversation going on.
Maybe we're all too busy coding? :)

[Karmac Coding]

How what I can tell, it looks like porting extensions requires writing
an idl and recompiling the extension. Is there a technical reason why
existing php extensions can't be taken into hiphop? It seems like the
interface for the php extensions are well defined and it is c/c++
code, so it should be possible. There are some vendors like
cybersource that release closed source php extensions that are needed
for e-commerce and that makes it a dealbreaker for some people. Not
to mention the huge amount of people that use extensions for all kinds
of things including debugging, profiling, and new functionality.

[Scott MacVicar]

Its just not compatible, the macros yeah but the bodies of certain functions just wouldn't copy over well.

In HipHop classes are *real* classes, unlike in PHP during module initialisation where an entry is set in a hash table. Along with functions etc.

Other data structures don't translate either.

The reason for the IDL is so that it tells the compiler about what values things can be so when it auto-generates the code the type inference can work correctly.

For the most part PHP is just a thin wrapper around another library, HipHop itself is very similar. If yo

- Scott

[Karmac Coding]

> Its just not compatible, the macros yeah but the bodies of certain functions just wouldn't copy over well.
>
> In HipHop classes are *real* classes, unlike in PHP during module initialisation where an entry is set in a hash table. Along with functions etc.
>
> Other data structures don't translate either.
>
> The reason for the IDL is so that it tells the compiler about what values things can be so when it auto-generates the code the type inference can work correctly.
>
> For the most part PHP is just a thin wrapper around another library, HipHop itself is very similar. If yo
>

That's too bad. Is it really impossible to map, or just difficult?

From what I can tell, there's only one main structure for the php
extensions...

/* {{{ counter_module_entry
*/
zend_module_entry counter_module_entry = {
STANDARD_MODULE_HEADER,
"counter",
counter_functions,
PHP_MINIT(counter),
PHP_MSHUTDOWN(counter),
PHP_RINIT(counter), /* Replace with NULL if there's nothing
to do at request start */
PHP_RSHUTDOWN(counter), /* Replace with NULL if there's nothing
to do at request end */
PHP_MINFO(counter),
"0.1", /* Replace with version number for your extension */
STANDARD_MODULE_PROPERTIES
};
/* }}} */

It doesn't seem like an impossible task to map the
minit,mshutodown,rinit,rshutdown, and minfo macros to the
corresponding module init/shutdown and request start/end functions in
hiphop.

Where is the part which cannot map to hiphop?

[Scott MacVicar]

This stuff yes, but the actual contents of the functions no. The MINIT functions register entries into hash tables that just don't exist. The memory manager is different, each class needs to extend our smart pointer class fro doing the refcounting but there is no class to extend in PHP since it's just hash table entries.

- Scott

[Karmac Coding]

If there is no way to make it binary compatible, is there any way to
make it source code compatible? We could map the macros to create the
real classes that hiphop needs for the minit process.