Simon, Em Quarta 03 Agosto 2011, você escreveu: > In that light you may want to explain why you need 2-5 since the > easiest way is to simply link to libphp.
Resources accessible to libphp through apache are limited by ssytem configurations. With libphp fully available to every user there are potential problems. For instance, snooping into system configurations especially in networked applications or a maliciously hacked user compiled libphp. About 2: the need for configuration changes tailored to local restrictions. Have convinced myself that building R_CMethodDef and R_CallMethodDef dinamically will be better. For instance, in a "precompiled scenario" php functions that make use of db4 libraries would cause a crash if those libraries are not available. About 5: a user could redefine parameters to "reuse" libphp directly using "good guy" loading mechanism of Rphp. While Rphp itself would be harmless, loading its library would make libphp available within the R process. R might be used as unsuspected hacking tool. I mean, exporting functions from libphp can be good or evil and potentially harmful without the limits imposed by apache and with the potential use of a hacked libphp. > As for 7, R uses mingw gcc (see Windows FAQ, we provide all the tools) > so as long as php can be built that way there should due no issues. I'll check that out asap. Regarding recursion and stack size, I have been assured by a php developer that it currently is not a concern. Have also found that a recursion problem with libpcre (used by libphp) has been solved. In a phrase: problems I foresee are related to deployment of libphp and potential security breaches. Thanx and cheers. -- Alexandre -- Alexandre Santos Aguiar, MD, SCT
signature.asc
Description: This is a digitally signed message part.
______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
