Hi Andreas,

> 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.

    It may sound like we have different opinions. But I know
    deep down in the corner of 'the secret chamber' we don't.
    You know what I mean (we both believe in plugins, don't we ;-)

> 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.

    No, I don't think the probability of getting into trouble is reduced
    when the plugins are builtin.

    Actually, by making all plugins external, that probability is reduced.

    This is because there are no internal plugins to conflict with external
    plugins. IMHO, this is the right thing to do. A plugin is inherently
    meant to be external.

> 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

    MobVM InterpreterProxy has been at 1.5 since 3.2.3 and that
    proxy already included the 64bit int values.

> and your proxy defines a whole lot of other things in this place.

    MobVM has included InterpreterProxy and InterpreterProxyEx for
    sometime. InterpreterProxy is used unchanged, all extra functionalities
    are exposed internally through InterpreterProxyEx.

    How's that for a design with foresight ;-)

> Considering this, it is not surprising that it almost immediately fails.

    Actually the failure came from the fact that MobVM external FilePlugin
    is a real plugin while the legacy megaVM builtin FilePlugin is actually
    a you_know_what_i_mean ;-)

> If I would send you an external file plugin your MobVM would break
> in equal horrible ways.

    I have a better idea, send me not just FilePlugin but also
    SecurityPlugin and DropPlugin as well as AsyncFilePlugin,
    MidiPlugin, SerialPlugin, SocketPlugin and SoundPlugin as
    a set of url for the gzipped files.

    It goes without saying that these must be genuine external plugins
    that work with the legacy megaVM. ;-)

    I will make sure that they work with MobVM and I will make sure that
    SqMOM.ini will point to the url for these official plugins.

    That's called collaboration ;-)

    And I will send you a good bottle of Ontario wine that I can afford.
    (That's called friendship ;-)

    Deal ?

> 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.

    Hey, why would I want to do this, and the problem is not in the proxy.

>> > 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?!

    The name of the plugin directory is in the [Plugins] section of SqM.ini:

        [Plugins]
        DirName=ImageBuilder

> But even if that's the case, I could still adapt that scheme
> and have everything builtin ;-)

    Of course, why not.
    (Hint, make all plugins external, then 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".

    Doesn't it come to you as a plesant surprise that since last release,
    MobVM also offers a "single file solution".

    Of course MobVM single file does not carry as much weight
     as the legacy VM single file (10K vs 1,000K ;-)

> If they don't, they are absolutely free to use MobVM.

    Thanks for your endorsement.

> Perhaps you don't realize this, but I am not at all opposed to MobVM -
> personally, I find it a refreshingly different approach.

    Thanks for confirming my hunch. I think you like it, right ;-)

> And the competition posed by it can only be helpful. But considering
> all the tradeoffs I will stick to a more conservative approach.

    Hey, why on earth do you think that MobVM is a competitor to
    Win32VM. It's just a model to show what a VM can be like.

    With a tiny bit of luck, that model can be implemented on other
    platforms as well ;-)

    Anyway, no itches are alike, right ;-)

    Cheers,

    PhiHo.