For example, you might like to move platforms/win32/vm/sqWin32Directory.c to platforms/win32/plugins/FilePlugin/sqWin32Directory.c

The point of which would be?! .... ;-)

Sorry, couldn't resist.

Cheers, - Andreas

Hi Jason,

And if you really have an appetite for plugins, please try MobVM.

Cheers,

PhiHo.

----- Original Message ----- From: "Jason Dufair" jase@dufair.org To: squeak-dev@lists.squeakfoundation.org Sent: Tuesday, December 10, 2002 12:25 AM Subject: Re: Which plugins?

I'd be glad to make changes so Squeak can compile with few (or no) plugins. I'll play with it tomorrow on my Win32 box (a nice 2.4GHz P4). I'll probably have less luck on my Linux box here as it's quite a dog (Celeron 400) and takes forever to compile Squeak.

Tim Rowledge wrote:

...

"Andreas Raab" andreas.raab@gmx.de is claimed by the authorities to

have written:

...

...

Yes, some of the plugins currently must be builtin. Call it sloppiness - since I always build VMs with everything builtin I hardly find the time to go over everything and fix those references.

Jason it sounds like you've been handed a perfect opportunity to make a valuable contribution to the world of Squeak ;-)

For example, you might like to move platforms/win32/vm/sqWin32Directory.c to platforms/win32/plugins/FilePlugin/sqWin32Directory.c

tim

Jason,

What are the tradeoffs pro/con of using MobVM vs. the standard VM?

As I see it, the disadvantage in using MobVM are:

1/- It takes more disk space.

2/- It is somewhat slower if you use separate InterpreterPlugin, ObjectMemoryPlugin and PrimitivesPlugin

3/- Not as much field tested as the standard VM.

The advantages are:

1/- It takes less disk space, smaller foot print at run time if you need only a subset of the bundled plugins buitlin the standard VM.

2/- More flexible you can run both VI3 and VI4 with MobVM. Other image formats should be easily accomodated..

3/- MobVM is supposedly 100% compatible with the standard VM. It can do anything that the standard VM can do, but not the other way around.

4/- It's easier to maintain and innovate. The work load can be easily distributed, because it is very modular.

Actually, you and others should try both MobVM and the standard VM and let us know what you think.

Cheers,

PhiHo.

Hi Andreas,

• Setup issues. Can MobVM *always* figure out what the "right" way to

access stuff on the web is?! Regardless of platform, browser setup etc?!

Browser setup is not relevant. MobVM uses the service provided by the OS directly.

I guess this feature is not crossplatform. Other platforms may have to implement differently.

What about fire walls, proxies and all of the other "niceties" of a modern computer setup?!

I think as long as we stick to HTTP, there won't be a problem.

If there is any problem, that's exceptional. I have not got any report on this kind of problems. If there are any coming, I will try to solve. (would someone please file a report having this kind of problem ;-)

• No "offline access". If you haven't accessed a specific plugin while

you were online you won't get it. Your ISP just had a power outage?! Uh, oh...

No problem, you can always download the whole thing in 1 zip file ;-)

And if there is a power outage right in your home, uh oh, good excuse for taking a break ;-)

• The possibility of "dll hell". Even today we have problems with what

(external) plugin exactly is used under which conditions. This problem grows exponentially with the number of plugins you have to worry about.

Not a problem, MobVM can look at just ONE place to find the plugin. We can design that ;-)

And if it is a problem, it's just the same problem that the classic VM must face when there are stray plugins hanging around at the riight place and right time ;-)

• The possibility of versioning conflicts (does MobVM actually have any

versioniong?!), both in the terms of "what plugin belongs to what VM version" as well as "what plugin does require a specific other plugin version".

It's not implemented yet, but it's anticipated, waiting for input.

Any ideas as how should we handle this versioning issue ;-)

( and the first release of MobVM was not even pre-Alpha, it was pre-existing ;-)

I think that the "impossibility to get anything wrong" clearly outweighs the (perceived or real) disadvantages of the "classic everything builtin" VM. That's a personal opinion of course.

What do you mean by "impossibility to get anything wrong" ?

Does the classic VM still load a (bad) extenal plugin even if it already had a good builtin plugin.

I told you about that many moons ago. I hope it's fixed now. :-)

Having jumped through all these loops, I wondwer if you recall that MobVM can be deployed with any plugin as internal or external. You have your choice.

You can build and deploy a mega MobVM with all plugins as internal. (just leave out the things you don't need)

The classic VM certainly cannot be deployed with all plugins as external.

Your arguments make me wonder why we had external plugins at all.

For that matter, it would be very much safer to stick with numbered primitives and expanding it.

Actually, we can still have named primitives but just forget about plugins. (make them all stuckins.;-)

You know, I anticipate that in another few decades, Squeak will have thousands and thousands of plugins, and I hate to distibute GB's VM ;-)

MobVM brings the concept of plugins to its height. !

Cheers,

PhiHo.

P.S: Will the classic VM support both VI3 and VI4 ? :-)

----- Original Message ----- From: "Andreas Raab" andreas.raab@gmx.de To: squeak-dev@lists.squeakfoundation.org Sent: Tuesday, December 10, 2002 9:36 PM Subject: RE: Which plugins?

Hi PhiHo,

I don't consider any of the disadvantages you mention to be really that important. The major problematic points I see are:

• Setup issues. Can MobVM *always* figure out what the "right" way to

access stuff on the web is?! Regardless of platform, browser setup etc?! What about fire walls, proxies and all of the other "niceties" of a modern computer setup?!

• No "offline access". If you haven't accessed a specific plugin while

you were online you won't get it. Your ISP just had a power outage?! Uh, oh...

• The possibility of "dll hell". Even today we have problems with what

(external) plugin exactly is used under which conditions. This problem grows exponentially with the number of plugins you have to worry about.

• The possibility of versioning conflicts (does MobVM actually have any

versioniong?!), both in the terms of "what plugin belongs to what VM version" as well as "what plugin does require a specific other plugin version".

The key reason why I am concerned about the above is that no newbie will be able to understand "what went wrong" if any of the above cause a problem. And not even you may... I had this problem recently with a few people where "Squeak crashed" and after a while we found that there were lingering plugins from some old Squeak installation being used...

I think that the "impossibility to get anything wrong" clearly outweighs the (perceived or real) disadvantages of the "classic everything builtin" VM. That's a personal opinion of course.

Cheers,

• Andreas

...

-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org] On Behalf Of PhiHo Hoang Sent: Wednesday, December 11, 2002 2:42 AM To: squeak-dev@lists.squeakfoundation.org Subject: Re: Which plugins?

Jason,

...

What are the tradeoffs pro/con of using MobVM vs. the standard VM?

As I see it, the disadvantage in using MobVM are:

1/- It takes more disk space.

2/- It is somewhat slower if you use separate InterpreterPlugin,
    ObjectMemoryPlugin and PrimitivesPlugin

3/- Not as much field tested as the standard VM.

The advantages are:

1/- It takes less disk space, smaller foot print at run

time if you need only a subset of the bundled plugins buitlin the standard VM.

2/- More flexible you can run both VI3 and VI4 with MobVM.
    Other image formats should be easily accomodated..

3/- MobVM is supposedly 100% compatible with the standard VM.
    It can do anything that the standard VM can do, but

not the other way around.

4/- It's easier to maintain and innovate.
    The work load can be easily distributed, because it

is very modular.

Actually, you and others should try both MobVM and
the standard VM and let us know what you think.

Cheers,

PhiHo.

Hi Tim,

...

As I see it, the disadvantage in using MobVM are:

You left out a pretty important one (at least, as of last time I looked at the code) which is that you depend pretty heavily on Windows functionality.

I would count that as an advantage ;-)

After all, these parts of the codes are platform specific.

So, with your pernission :-) :

"Advantages in using MobVM are:

blah blah blah

...Windows functionality is beautifully leveraged... ;-) ... "

Seriously, I don't think that's much of a problem for other platforms to provide the functionality to access ini file like under Windows. They can use properties file instead.

Then, again, ini file has been used in Squeak since the dinosaurs still wandering around ;-)

That's said, I vaguely recall, there is even a cross platform lib to handle ini file.

I'm sure the concept could be applied cross platform (well as long as the target can actually handle dynamic loading at all)

I guess Unix, Mac and WinCE do support that. Does Acorn support dynamic loading ? (and any other platforms that currently have Squeak port and do not support dynamic loading ?)

IIRC there are a lot of places where the code is manualy hacked about that would need cleaning up.

Your help is very much appreciated.

Also, I found that the macro 'XNAME' is very convenient, please consider to restore it and use it consistently in all plugins so that one can choose either to work with fully qualified exported names or not.

Should macros to access the interpreter proxy be placed in a common header file ?

BTW, how is the DisplayPlugin you mentioned before, should I change MobVM WindowPlugin to DisplayPlugin ?

It's more generic and neutral. Squeak doesn't have to display to a window, remember, we are in the Morphic world :-)

Besides, WindowPlugin maybe confusing, making people think that plugin will provide Windows functionality ;-)

Cheers,

PhiHo.

----- Original Message ----- From: "Tim Rowledge" tim@sumeru.stanford.edu To: squeak-dev@lists.squeakfoundation.org Cc: "Tim Rowledge" tim@sumeru.stanford.edu Sent: Thursday, December 12, 2002 11:36 AM Subject: Re: Which plugins?

On Tuesday, December 10, 2002, at 05:42 PM, PhiHo Hoang wrote:

...

Jason,

...

What are the tradeoffs pro/con of using MobVM vs. the standard VM?

As I see it, the disadvantage in using MobVM are:

You left out a pretty important one (at least, as of last time I looked at the code) which is that you depend pretty heavily on Windows functionality. IIRC there are a lot of places where the code is manualy hacked about that would need cleaning up.

I'm sure the concept could be applied cross platform (well as long as the target can actually handle dynamic loading at all) with some more work. After all, I claimed it could back in '95 when trying to persuade my then-boss at ParcPlace...

tim

tim@sumeru.stanford.edu

Bert Freudenberg wrote:

On Thu, 12 Dec 2002, PhiHo Hoang wrote:

...

Then, again, ini file has been used in Squeak since the
dinosaurs still wandering around ;-)

I never saw something even remotely resembling an ini file in Squeak in my wigwam[*]. What are you talking about?

Sorry, I stand corrected, "ini file has been used in Windows Squeak since the dinosaurs still wandering around" ;-)

[*] No Gates, no Windows, but an Apache inside.

It should be stressed that the 'A' must always be UPPERCASE.

Never say :

'No gates, no windows but an apache inside'

especially if you are in Paris ;-)

http://www.webster.com/cgi-bin/dictionary

Cheers,

PhiHo.