Guillaume,

> 	I want to know if the squeak interpretor is thread-safe.
> Because I would like to compile it as an ActiveX that 
> implements the IActiveScript interface (WIN32 platform specific, sorry).

Hm ... sounds like an interesting project to me. If you're really going to
do this (requires quite a bit of knowledge about some Win32 stuff) please
keep me informed.

> Such ActiveX are interpretors for scripting langages in 
> IE or windows scripting host. Microsoft provides DLLs
> for JScript and VBScript, but they don't fit well with 
> heavy-scripted pages on the client-side and someone has 
> made a PERL implementation also. Using
> squeak would enable scripting like this I guess :
> <SCRIPT language="squeak">
> 	(NodeList with: (document tags: "DIV")) do: [:t | t innerHTML:
> "<H1>Foobar</H1>"]
> </SCRIPT>
> 
> This raises a few questions :

Let me ask a question before I go on to your stuff. If you want to use a
script like the above you have to make sure that a class like NodeList is
known to the environment. Have you thought about how this could be handled?!
E.g., do you want to provide a full image for this purpose or are you
planning to start with something like:

<SCRIPT language="squeak">
	Smalltalk 
		loadClassNamed: #NodeList 
		url: 'myHost.myDomain/NodeList.st'.
	...
</SCRIPT>

I guess you would be better off using the latter since how should the script
know what's already there and what isn't. The difference is basically how
large an image you want to start with. This is a somewhat important question
because...

>  - is the interpretor thread-safe ?

.... neither the interpreter nor the the image side is completely thread
safe. Sounds bad, I know. It is, however, not as complicated as it sounds if
you're using a little trick (which I am using for the Squeak plugin). What
happens is that in the plugin Squeak is actually started in it's own process
every time you open a plugin window (e.g., even if you have two <embed> tags
on the same page). This has certain advantages (like Squeak running in its
own address space, being automatically 'thread' safe etc) though it has some
disadvantages - the major one is that it does require space for each
invokation of Squeak. And that's where the size of the image comes into
play. If you could initially start with a really stripped down image (<=
1MB) you should be able to just start a new session every time.

>  - can the image be stripped easily of all display-related stuff ?

Not sure what you mean by this. The image can be run without the display
showing (just start it with the option '-headless') but ripping out all of
the display stuff sounds kinda hard to me.

>  - how do I wrap an external COM object into a squeak object ?

This is a question that you'll have to decide for yourself since you will
have to figure out the communication channels between the scripting
interface and Squeak anyways. As an example, the plugin just passes all the
parameters specified in the embed tag as command line parameters so that
they're accessible from Smalltalk using #getSystemAttribute - you could just
use a temporary file for this, or sockets or whatever more [side note: I'm
thinking of giving Squeak access to pipes for several purposes and this
might be helpful as well]

  Andreas