[Mono-dev] WCF in Moonlight

Atsushi Eno atsushi at ximian.com
Tue Aug 19 08:13:57 EDT 2008

Hey JB,

> Hey all,
> Silverlight 2.0b2 contains three assemblies that we do not provide yet:
> * System.ComponentModel
> * System.ComponentModel.Web
> * System.Runtime.Serialization

You meant System.ServiceModel*.

> Currently, we have parts of those assemblies implemented in the olive
> module. We could either:
> 1) depend on olive, and tune the assemblies there.
> 2) move those assemblies to the mcs module, and tune them there.
> According to the discussion we had on IRC, it seems that 1) is a no
> go, as we don't want to release olive, and we rather avoid to add
> another dependency to moon.
> How to do 2) properly then? Should we simply move those assemblies to
> mcs, and develop there, or continue to develop in olive, and merge
> changes when we feel confident into mcs? I'd rather simply move them,
> but then we would have unstable assemblies in mcs. Should we apply the
> same policy we apply for Cecil, that is not exposing it to the
> compiler without using a pkg?

Most generally, we have two choices:

	A) abandon existing premises (mcs => stable, olive => unstable)
	B) keep stability premises above.

I rather prefer A) as it is closer to our fact. Stable assembly and
unstable assembly can be distinguished from some explicit declaration
e.g. in our documentation and/or website.

Even if it comes to B), "stability" could be evaluated in two ways:

	1) public API stability
	2) implementation stability

Since 2) has never been achieved in every assembly, and we have a lot
of unsupported assemblies under mcs (e.g.System.EnterpriseServices.dll),
I'd say "stability" is almost all about 1).

API stability can be achieved relatively easily than implementation

> Also, Atsushi, how complete is our implementation wrt what SL2 ships?

No idea. The last maintainers were not me but Mainsoft guys.

Atsushi Eno

More information about the Mono-devel-list mailing list