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

[Kunle O. <kun...@vi...>]

> - Nant
>=20
> As I have said in the last 2 days, the platform can now be=20
> build using Nant scripts (i.e., no VS needed).

Woo-hoo!


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

+1

> - AppDomains
>=20
> OK. Long one approaching. Take a deep breath and then dive in.
>=20
> After doing some research on AppDomains, I jotted down the=20
> ups and downs of using AppDomains in the plug-in based=20
> architecture. They are:
>=20
> + supports unloading of Assemblies (IF they are not domain-neutral)
> - each assembly should have multiple copies of itself in some=20
> AppDomains (and subsequent overhead of JITting for each=20
> assembly), because of assembly dependencies (again, unless=20
> the assemblies were loaded as domain-neutral; in that case,=20
> 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()=20
> 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=20
> (domain-neutral) assembly will only be unloaded when the=20
> process is terminated
> + increased security (an assembly going kaboom in 1 AppDomain will not
> affect other AppDomains)
>=20
> All this said, I started thinking about the implications of=20
> using AppDomains in our plugin architecture. I think the=20
> performance hit would be worth it, given the increased=20
> security advantage. And the usage of AppDomains would=20
> certainly be appliable to a plugin architecture where plugins=20
> are not related to one another (no dependencies on each other, etc.).
>=20
> However, there are some aspects of our architecture that should be
> considered:
>=20
> A - plugins _are_ aware of each other, as they can be related=20
> (through plugin imports)
>=20
> Because of Statement A, I guess we have 2 choices: load all=20
> assemblies as domain-neutral or in each AppDomain, load a=20
> copy of all necessary assemblies (plugin assemblies +=20
> assemblies of plugins imports). I think the second choice is=20
> unacceptable, as this would boost memory consumption n-fold.=20
> However, if we go towards the first choice, we can't unload=20
> assemblies (because they're domain-neutral).

Load all plug-ins into a second appdomain that can be recreated on =
demand.
All plug-ins implement interfaces in a helper assembly that can be =
loaded as
domain-neutral?. All interaction with plug-ins is via the interface.

This needs testing/refining/validation actually. Just off the top of my
head.

Kunle