gmane.comp.gnome.mono.devel

Jb Evain | 19 Aug 12:44

WCF in Moonlight

Hey all,

Silverlight 2.0b2 contains three assemblies that we do not provide yet:

* System.ComponentModel
* System.ComponentModel.Web
* System.Runtime.Serialization

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?

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

--

-- 
Jb Evain  <jb <at> nurv.fr>

(Continue reading)

Atsushi Eno | 19 Aug 14:13

Re: WCF in Moonlight

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:

(Continue reading)

Jb Evain | 19 Aug 15:51

Re: WCF in Moonlight

Hey,

On 8/19/08, Atsushi Eno <atsushi <at> ximian.com> wrote:
>  You meant System.ServiceModel*.

Of course, thanks :)

>  Most generally, we have two choices:

Another option I'm thinking about, is to have SL2 *only* versions of
such assemblies in mcs. That is, the code still lives in olive, and is
developed there, and we manually backport code to mcs, where those
assemblies are built only for the net_2_1 profile.

That would avoid to move all the WCF assemblies to mcs, such as
System.IdentityModel* that will be needed for the non plugin version
of System.ServiceModel.

On the other hand, am thinking that if we start moving code into mcs,
we might as well move all the required code for all usages, so I have
mixed feelings about that option.

--

-- 
Jb Evain  <jb <at> nurv.fr>

Atsushi Eno | 19 Aug 18:39

Re: WCF in Moonlight

Hola,

> Hey,
> 
> On 8/19/08, Atsushi Eno <atsushi <at> ximian.com> wrote:
>>  You meant System.ServiceModel*.
> 
> Of course, thanks :)
> 
>>  Most generally, we have two choices:
> 
> Another option I'm thinking about, is to have SL2 *only* versions of
> such assemblies in mcs. That is, the code still lives in olive, and is
> developed there, and we manually backport code to mcs, where those
> assemblies are built only for the net_2_1 profile.

Ah, that sounds clever ;) In that way we could also use some sort of
configuration option like --enable-preview to determine whether to build
3.0 assemblies or not. They can be skipped when it is not enabled.

Atsushi Eno

Miguel de Icaza | 19 Aug 19:58

Re: WCF in Moonlight

> Hello,

> > Silverlight 2.0b2 contains three assemblies that we do not provide yet:
> > 
> > * System.ComponentModel
> > * System.ComponentModel.Web
> > * System.Runtime.Serialization
> 
> You meant System.ServiceModel*.

The assemblies shipping with Silverlight 2.0 are:

	System.Runtime.Serialization.dll
	System.ServiceModel.Web.dll
	System.ServiceModel.dll

I do not see references to System.ComponentModel assemblies, at least
not with the runtime, maybe the SDK has them, but we can safely ignore
those.

Jb Evain | 19 Aug 20:00

Re: WCF in Moonlight

Hey,

On 8/19/08, Miguel de Icaza <miguel <at> novell.com> wrote:
>  > > Silverlight 2.0b2 contains three assemblies that we do not provide yet:
>  > >
>  > > * System.ComponentModel
>  > > * System.ComponentModel.Web
>  > > * System.Runtime.Serialization
>  >
>  > You meant System.ServiceModel*.
>
> The assemblies shipping with Silverlight 2.0 are:
>
>         System.Runtime.Serialization.dll
>         System.ServiceModel.Web.dll
>         System.ServiceModel.dll
>
>  I do not see references to System.ComponentModel assemblies, at least
>  not with the runtime, maybe the SDK has them, but we can safely ignore
>  those.

It was a typo in my mail, there's no System.ComponentModel assemblies in SL2.

--

-- 
Jb Evain  <jb <at> nurv.fr>

Miguel de Icaza | 19 Aug 19:45

Re: WCF in Moonlight


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

Lets move the assemblies into mcs.   There are plenty of pros and cons
to various other approaches (like stabilizing Olive and depending on it)
but it will be cumbersome and will add another dependency.

Jb Evain | 19 Aug 20:08

Re: WCF in Moonlight

Hey,

On 8/19/08, Miguel de Icaza <miguel <at> novell.com> wrote:
> Lets move the assemblies into mcs.

Ok. That will require to move the folders:

* System.Runtime.Serialization
* System.IdentityModel
* System.IdentityModel.Selectors
* System.ServiceModel
* System.ServiceModel.Web

from olive to mcs.

Right now, for the desktop case, they're built and installed in the
3.0 profile of olive, and installed in $(prefix)/mono/lib/3.0, people
have to use -pkg:olive to reference them. Do we want to preserve that
when being built in mcs, or should we simply build and install them in
the 2.0 profile?

--

-- 
Jb Evain  <jb <at> nurv.fr>

Miguel de Icaza | 19 Aug 20:42

Re: WCF in Moonlight

Hello,

> On 8/19/08, Miguel de Icaza <miguel <at> novell.com> wrote:
> > Lets move the assemblies into mcs.
> 
> Ok. That will require to move the folders:
> 
> * System.Runtime.Serialization
> * System.IdentityModel
> * System.IdentityModel.Selectors
> * System.ServiceModel
> * System.ServiceModel.Web
> 
> from olive to mcs.
> 
> Right now, for the desktop case, they're built and installed in the
> 3.0 profile of olive, and installed in $(prefix)/mono/lib/3.0, people
> have to use -pkg:olive to reference them. Do we want to preserve that
> when being built in mcs, or should we simply build and install them in
> the 2.0 profile?

Mhm, good question.   I guess it should go into the 2.0 directory, to be
a default reference, and we should also add some new .pc files -pkg:wcf
and -pkg:cardspace

Does that make sense?

Jb Evain | 19 Aug 20:51

Re: WCF in Moonlight

On 8/19/08, Miguel de Icaza <miguel <at> novell.com> wrote:
> I guess it should go into the 2.0 directory, to be
> a default reference, and we should also add some new .pc files -pkg:wcf
> and -pkg:cardspace
>
> Does that make sense?
>

Makes sense to me, I'll work on moving them, integrating them in the
build and adding support for them in the tuner tomorrow.

--

-- 
Jb Evain  <jb <at> nurv.fr>

Atsushi Eno | 20 Aug 03:13

Re: WCF in Moonlight

Miguel de Icaza wrote:
> Hello,
> 
>> On 8/19/08, Miguel de Icaza <miguel <at> novell.com> wrote:
>>> Lets move the assemblies into mcs.
>> Ok. That will require to move the folders:
>>
>> * System.Runtime.Serialization
>> * System.IdentityModel
>> * System.IdentityModel.Selectors
>> * System.ServiceModel
>> * System.ServiceModel.Web
>>
>> from olive to mcs.
>>
>> Right now, for the desktop case, they're built and installed in the
>> 3.0 profile of olive, and installed in $(prefix)/mono/lib/3.0, people
>> have to use -pkg:olive to reference them. Do we want to preserve that
>> when being built in mcs, or should we simply build and install them in
>> the 2.0 profile?
> 
> Mhm, good question.   I guess it should go into the 2.0 directory, to be
> a default reference, and we should also add some new .pc files -pkg:wcf
> and -pkg:cardspace

Do we really want such individual packages, especially even if
we come up with WPF and WF (WF assemblies actually exists) ?
Since they are not supported assemblies, we could rather live without
them, or something like pkg:dotnet-preview would be better (just to
replace olive, minus UIA stuff).

(Continue reading)

Miguel de Icaza | 20 Aug 19:17

Re: WCF in Moonlight


> At least -pkg:wcf and -pkg:cardspace sounds identical.
> 

Ok, then lets just use wcf.

| 19 Aug 20:57

Re: WCF in Moonlight

Miguel de Icaza wrote:
>> 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?
> 
> Lets move the assemblies into mcs.   There are plenty of pros and cons
> to various other approaches (like stabilizing Olive and depending on it)
> but it will be cumbersome and will add another dependency.

We were discussing about a similar issue inside the UIA team. Can we 
then take a similar approach for our assemblies in olive when our 
release dates arrive?

	Andrés

--

Miguel de Icaza | 19 Aug 21:51

Re: WCF in Moonlight


> We were discussing about a similar issue inside the UIA team. Can we 
> then take a similar approach for our assemblies in olive when our 
> release dates arrive?

We will discuss that case later.

Return

Return to gmane.comp.gnome.mono.devel.

Advertisement

Project Web Page

Mono development list.

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane