Hi PhiHo,

I guess we simply have different opinions on that matter. All my experience
drives me strongly into the direction of "if possible have all plugins
builtin" but I can certainly understand that other people may have other
opinions about this. Nonetheless I'd like to point out two things:

>     My 'weird problems' reported in previous posting is proof that
>     the conservative approach doesn't solve the 'plugin 
> 	conflict' problem.
[...]
>     I proved that the 'builtin' solution does not solve the 
> 	problem.

If you read my message carefully, then I am saying "in the vast majority of
cases" and "as far as possible". I never claimed that the current solution
completely solves this problem but it reduces it to a manageable amount.

Also, your "proof" relies heavily on a mismatch in the proxy numbers. The
current vm proxy version is 1.5 including the 64bit int values and your
proxy defines a whole lot of other things in this place. Considering this,
it is not surprising that it almost immediately fails. If I would send you
an external file plugin your MobVM would break in equal horrible ways. So I
think your proof is not exactly convincing. Hint: define yourself a new
proxy major version instead of using v1. Then retry your proof.

> > As you don't have an answer to this problem 
> 
>     I think I do. Did you notice that for the last couple 
> 	releases of MobVM.
>	the plugin directory is changed automagically.

No I didn't notice (my fault). I need to check this out - what is used to
determine the directory name?! But even if that's the case, I could still
adapt that scheme and have everything builtin ;-) The mere fact that it is
possible to handle the conflict problem (assuming it really is) doesn't
change the fact that most users feel very happy with a "single file
solution". If they don't, they are absolutely free to use MobVM. 

Perhaps you don't realize this, but I am not at all opposed to MobVM -
personally, I find it a refreshingly different approach. And the competition
posed by it can only be helpful. But considering all the tradeoffs I will
stick to a more conservative approach.

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of PhiHo Hoang
> Sent: Monday, March 10, 2003 4:49 AM
> To: The general-purpose Squeak developers list
> Subject: Re: [Win32][ANN][TEST][VM] Yet another Win32 VM (3.4.2)
> 
> 
> Hi Andreas,
> 
> > What's the point of your message? I see a vast number of 
> arguments that seem
> > to be making _my_ point rather than yours as the problems 
> you describe
> > clearly result from plugin conflicts. 
> 
>     If you read between the paragraphs and between the lines,
>     you will see I made _my_ points quite clear and strongly sound.
>     (and it's not the first time either ;-)
> 
> > As you don't have an answer to this problem 
> 
>     I think I do. Did you notice that for the last couple 
> releases of MobVM.
>     the plugin directory is changed automagically.
> 
>     From next release, there will only be SqM.exe and SqM.ini 
> at the root.
>     SqMOM.ini and all dll are in the plugin directory, the 
> name of which is
>     different from release to release.
> 
> > it appears to me that the more conservative approach of having
> > everything builtin is clearly preferrable (since it rules 
> out the vast
> > majority of the problems you are seeing).
> 
>     My 'weird problems' reported in previous posting is proof that
>     the conservative approach doesn't solve the 'plugin 
> conflict' problem.
> 
> > Also, as for "eating your own dog food" I do this on a 
> daily basis as I am
> > running a variety of VMs and images in various combinations. 
> 
>     There are many different "dog food" waiting to be eaten ;-)
>     The two that I am referring to are the 'dynamic, late binding'
>     and 'true plugin'.
> 
> > It is _exactly_ this what led me to come to the conclusion that 
> > for the end-user the best you can do is to provide a solution which 
> > rules out the potential for conflicts as far as possible.
> 
>     I proved that the 'builtin' solution does not solve the 
> problem.   
> 
> > Considering this, what is it you are trying to say?
> 
>     Considering that the 'builtin' solution does not solve 
> the problems
>     that it was suppoed to solve.
> 
>     Considering that the new design of looking for the plugins only
>     at one known location does solve the problems of conflicting
>     plugins.
> 
>     Considering that true plugins are nicer and better designed 
>     than stuckins.
> 
>     Considering that MobVM can do anything that the legacy VM
>     can do and NOT the other way around (due to the fact that
>     MobVM is pretty well componentized).
> 
>     I would say that let's perfect the plugin design.
> 
>     Let's componentize the VM.
>     Let's make everything an object from ground zero.
>     Let's make a Window/Display object, a BrowserPlugin object.
>     Let's make a BytecodeInterpreter object.
>     Let's make an ObjectMemory object.
>     Let's make everything an object, even in the VM
> 
>     I know, I know, I know,
>     I am 'preaching to the choir'.
> 
>     Better shut up now ;-)
> 
>     Cheers,
> 
>     PhiHo.
> 
>     P.S: It takes an intelligent person to come up with a 
> nice solution .
>             It takes an equally intteligent and wise and 
> brave person to 
>             regconise the short comings of his solution and 
> correct them.
> 
> 
>