[Eclipsedotnet-developers] Some considerations to plague our Christmas...

[<jpp...@gm...>]

Sorry for the title, but I didn't think of anything better.

OK, people, I expect this mail to be a bit long, so bear with me, please.


- Nant

As I have said in the last 2 days, the platform can now be build using Nant
scripts (i.e., no VS needed). Building through Nant automatically sets up
all files in their right places for a first execution of the platform.
Building through VS only builds the assemblies, it doesn't copy the
auxilliary files necessary.
So, the bin module is now obsolete (although I haven't deleted anything from
it yet).

----------------------------------------

- SWF_UI

The src_platform module has, for some time now, included a sub-project
designated SWF_UI (short for System.Windows.Forms User Interface). I have
already committed some code to it (mostly utility classes that would be
helpful in path that we took: registries, etc.). The idea is to define a set
of plugins (like the ones for SWT) that provides a UI based on WinForms.
However, and this is a personal opinion only, I would not support a simple
"port" of Jface and above plugins to use WinForms instead of SWF; instead, I
would go for maintaining important concepts like the Viewers (which I think
give Eclipse a lot of its power) and Windows/WindowManagers (although the
Window concept would probably need some heavy adjusting, as WinForms
simplifies many of the tasks involved with creating an SWT shell/window).

----------------------------------------

- SWT_UI

SWT_UI has had a lot of bug corrections, as you may have noticed. However,
as Kunle Odutola pointed out some time ago, the SWT plugin is still using
IKVM (and I think that is one big reason of why the platform is so slow and
memory-consuming: the average memory used is about 40 MBs, which I consider
very heavy). So, a conversion of SWT to C# could be based entirely on
System.Drawing or (like Eclipse's SWT approach) defining an API in managed
code, and that API would sometimes invoke platform-specific code. I
personally would go for the System.Drawing approach, as it would make
porting to other platforms (like Mono on Windows, Linux, etc.) much easier
(it would only depend on System.Drawing being available in such a platform).

----------------------------------------

- AppDomains

OK. Long one approaching. Take a deep breath and then dive in.

After doing some research on AppDomains, I jotted down the ups and downs of
using AppDomains in the plug-in based architecture. They are:

+ supports unloading of Assemblies (IF they are not domain-neutral)
- each assembly should have multiple copies of itself in some AppDomains
(and subsequent overhead of JITting for each assembly), because of assembly
dependencies (again, unless the assemblies were loaded as domain-neutral; in
that case, there would be only 1 copy of each assembly in the entire
Application)
- performance hit (due to crossing of AppDomain boundaries)
- no LoadFrom() methods like in Assembly class, only Load() methods (i.e.,
you can only load strong-named assemblies)
- an assembly is only unloaded (when the corresponding AppDomain is
unloaded) if it is not domain-neutral; otherwise, the (domain-neutral)
assembly will only be unloaded when the process is terminated
+ increased security (an assembly going kaboom in 1 AppDomain will not
affect other AppDomains)

All this said, I started thinking about the implications of using AppDomains
in our plugin architecture. I think the performance hit would be worth it,
given the increased security advantage. And the usage of AppDomains would
certainly be appliable to a plugin architecture where plugins are not
related to one another (no dependencies on each other, etc.).

However, there are some aspects of our architecture that should be
considered:

A - plugins _are_ aware of each other, as they can be related (through
plugin imports)

Because of Statement A, I guess we have 2 choices: load all assemblies as
domain-neutral or in each AppDomain, load a copy of all necessary assemblies
(plugin assemblies + assemblies of plugins imports). I think the second
choice is unacceptable, as this would boost memory consumption n-fold.
However, if we go towards the first choice, we can't unload assemblies
(because they're domain-neutral).

So, either we stick with what we already have or we define a way to use
AppDomains in this architecture. I would personally tend towards the first,
not because of the work I invested in it but because of the practicality of
it (right now, marshalling and app-domain boundary crossing comes to mind).

Nevertheless, this is the impression I got from my research. In "real life",
things could be harder than I said (or they can also be easier). If anyone
knows something about AppDomains, be sure to put a mail in here.

----------------------------------------

Just my 0.02 * 4 cents.

I expect feedback from everyone regarding any (or all) of these matters so
"let the games begin".

Regards,
JS

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.3/209 - Release Date: 21-12-2005