At 01:31 AM 2/17/2002, you wrote:
>Hi Rob,
>
>         Please find attched the makefile for SqM, actually something
>similar was posted together with the PDK sometime ago. Actually, it does
>not have support for Mpeg3Plugin and few other limitations.

PhiHo, this is excellent, thank you for the file.  I'll see where this 
takes me over the next few weeks.  I find it interesting that you have 
pluginized the interpreter.  :)   I am basically needing to build your 
MEGAVM with some list of external plugins, based on file system 
loccation.  src\plugins\* for external and src\vm\intplugins\* for internal.


> > While we discussing, is there a place to download your MobVM sources?
>
>         Because of the transition from home.com to rogers.com for my
>ISP, my web site disappeared since the end of Jan. ;-)

I'm guessing that they decided to do this to you?  I have had the same 
experience with AT&T.  It's not a pleasant one.


> > Perhaps there is a way to incorporate this into the 3.3 VM when we
>start on that.
>
>         I really hope so, that's why I sent the full source of the first
>version to SqC via Andreas. I am not quite sure it's a help or hinder to
>release MobVM at this stage.

It is always good to see sources, so we can learn new things.  That's a big 
difference from officially releasing it.

>         Does it help with the modularizing process. Can it get help from
>the experts to incorporate into the official VM ? As I said before, this
>is only a proof of concept and a quick prototype in C ;-)
>
>         There are some small incompatilities, and I do not like the idea
>of a fork in the VM at this stage.

Well, I suppose that technically the SF sources + VMMaker represent a fork 
in the VM.  The reason I mentioned 3.3a VM, is that it is alpha and we 
could experiment with it.  From a quick look at the makefile and recalling 
your SqM.exe, You included zip support and download support but pluginized 
the Intepreter out.  If we can add a certificate capability plus a 
certificate authority, like SqF, then we could change the deployment model 
of the VM, if we wished to.  I could imagine extending your VM loader to be 
version aware.  For example, if I have an image version 3.2, I would d/l 
the current InterpreterPlugin, versus a 3.3a + BC image which would d/l the 
BC3InterpreterPlugin.

it's good to see you back on the list!
Rob