On 2/12/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
[snip] Andrew Borley wrote: > Further things that could be done: > Demonstrate use of more than one language/SCA runtime. Currently all > components are implemented in Python. There is a Ruby version of the > POPChecker, but I hit threading issues when I tried to use this under > HTTPD so I had to replace it with a Python version. The Ruby 1.8.5 interpreter is not thread safe. To work around this limitation on Windows (where HTTPD runs multithreaded) we can use CGI (or FastCGI like many Ruby on Rails users do). Note that this is not really a problem on Linux where most people run multiple HTTPD processes instead of threads. I have started a CGI variation of the server side REST binding support. This can be an interim solution on Windows until the Ruby interpreter becomes thread safe, as well as a super easy way to test REST based applications outside of the server, just from the command line... BTW your Web 2.0 sample app is really cool!! -- Jean-Sebastien --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] For PHP we have set ourselves up to modify the Tuscany Native SCA PHP
extension to allow PHP to act as the hosting environment, i.e. we rely on PHP's existing integation with HTTPD to do the work for us. The advantage to us is 1/ To the PHP developer their deployment story is that same as for any other PHP application. I.e. they drop PHP scripts into the document root. 2/ They do need extra infrastructure and don't need to mess with the HTTPD configuration, i.e. PHP would load a PECL extension which in turn would load the Tuscany Native librarys. This solution still has problems in the LAMP hosted environment but it is at least familiar to the PHP developer. 3/ Close integration between PHP SCA/Tuscany Native SCA without recourse to remote bindings. Don;t have a specific use case but many PHP extensions are wrapped libraries so this provides an alternative high performance (?) mechanism for introducing native application level components to a PHP application. We haven't actually made this run but we have constructed the PHP extension to allow us to do this fairly easily. Anyhow just thought I would share this thought as it seems to fit in with what Jean-Sebastien is suggesting as a stop gap for Ruby. Regards Simon
