Hey,

I've been doing some tinkering over the last 24 hours and I've implemented
IActiveScript (and friends) as a SAPI for win32/IE.

What does that mean??  Well, it means that you can do things like this:
(in IE)

<html>
   ...
   <script language="ActivePHP">
        function clickit() {
           $GLOBALS["window"]->open("http://www.php.net";);
        }
   </script>
   
   <img onclick="clickit();">
</html>

Yes, that's PHP on the client side!

You can also invoke the engine for Windows Script Hosts (or any other
IActiveScriptSite implementation), and in theory you can even run scripts
with a mixture of JScript, VBScript, Perl, Ruby and PHP in them, with
methods calling in between the engines :-)

Oh yeah - you can probably use it for ASP and ASP.NET too (haven't tried
that yet!).

What I have at the moment is still very experimental; the features that
are missing are:
- no event sinking (apart from declaring handlers in attributes)
- error handler is not yet tied into the script host error/exception
  mechanism.
- other engines cannot call into PHP yet.  That's because we don't have
  a standard method of exporting PHP objects as IDispatch-able COM objects.

Unfortunately, because PHP is so powerful, it's really not a good idea
to author web pages for public consumption using client-side PHP.
IE will warn you that viewing such a page is unsafe.
I'm not bothered by that: my intention is to use it embedded in a win32
host application.

The IActiveScript architecture is not too bad, so implementing this wasn't
such a hardship.  However, since the host may have multiple engines on
the same thread, the php4activescript implementation creates a thread for
each instance of a scripting engine.  That lead to some "interesting" code
to ensure that the right things were called in the right threads...

Performance-wise, there are two things that would be really beneficial
for php4activescript - although I dont expect to have these any time
soon, I'm highlighting them in case someone has alternative solutions:

- Delayed bindings for globals.  The scripting hosts register a good dozen
  or so COM objects in the global namespace.  PHP has to activate and make
  a couple of calls for each object imported in that way so that it can
  create a COM wrapper object (from the COM extension) for each object,
  even if it is not used.  It would be nice to activate the object the first
  time the global symbol is used.

- Scripting engine persistance mechanism.  Being able to make a persistent
  (as in pmalloc) copy of zend_op_array's would do just fine.
  I know this is not easy because of all the emalloc'd data in there.
  Alternatively, it would be nice to be able to convert a zend_op_array
  back into a string representation of the code.  The reason for this is
  that script hosts will create an instance of the engine, parse the script,
  clone the engine and then run the cloned instance.  Because of the PHP
  architecture, we need to re-compile the code on the newly cloned thread :-/

Right, I'm going to delve back into it - I just wanted to sound things out,
and see if anyone has any ideas about these things.

--Wez.


-- 
Wez Furlong
The Brain Room Ltd.


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to