[Opensim-dev] Security: multiple or the most generic?
Diva Canto
diva at metaverseink.com
Tue Apr 14 15:14:05 UTC 2009
One of the really interesting things about OpenSim, at least for me, is
its goal of becoming a framework for VW application development. Yes,
OpenSim has Second Life as the reference application, and it's really
easy to forget that SL is just a reference. And as we identify the
weaknesses of certain features of SL (be it security, groups, ...), it's
also really easy to fall into designing "the best" alternatives to those
features and hard-code them in OpenSim. But honestly, I think that
looses that important property of OpenSim wanting to be an extensible
collection of utilities that people can put together in different ways
to create different applications.
While I am personally more interested in an application that resembles a
web of VWs, I can understand lots of other use cases / applications that
aren't like that.
The issue of server-side vs. client-side TPs is at the core of this
dilemma. There is no doubt in my mind that client-side TPs are the most
generic form of agent transfers, and they are required for a web of VWs.
However, it's clear that client-side TPs depart from use cases where the
server side has complete control of the agents. Even though I'm not
particularly interested in those use cases, I don't think we should
throw them away, because they are valid for other people.
So, as far as I'm concerned, OpenSim will always support both.
We may need to rearchitect things a little bit for this to happen
nicely, because right now things are heavily tuned towards server-side
authority.
Melanie wrote:
> It seems you're forgetting the valid use case of multi-server sites.
> Ultimate trust within a domain (today's "Grid") is a valid use case.
>
> Melanie
>
> DZO wrote:
>> It may seem that by supporting as many of these as possible its making the
>> task easier for the client, but I believe making a very generic version of
>> option C, allowing each region to be customised to require varying levels of
>> protection and pushing back the ease off use issue to the client would make
>> the task simpler for opensim AND give the client the freedom to choose.
>>
>> For example you can attach multiple logins to an im messenger application or
>> an email client, and use all of them seemlessly from one computer, so the
>> viewers should be able to store grid / region passwords and manage them,
>> allowing for strict password protection even on a region basis yet seemless
>> useage / teleporting / walking for the client.
>>
>> -----Original Message-----
>> From: opensim-dev-bounces at lists.berlios.de
>> [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of
>> opensim-dev-request at lists.berlios.de
>> Sent: 14 April 2009 00:20
>> To: opensim-dev at lists.berlios.de
>> Subject: Opensim-dev Digest, Vol 20, Issue 35
>>
>> Send Opensim-dev mailing list submissions to
>> opensim-dev at lists.berlios.de
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>> or, via email, send a message with subject or body 'help' to
>> opensim-dev-request at lists.berlios.de
>>
>> You can reach the person managing the list at
>> opensim-dev-owner at lists.berlios.de
>>
>> When replying, please edit your Subject line so it is more specific than
>> "Re: Contents of Opensim-dev digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Security: multiple or the most generic? (Diva Canto)
>> 2. Re: Security: multiple or the most generic? (Diva Canto)
>> 3. Re: Security: multiple or the most generic? (Ideia Boa)
>> 4. Re: Security: multiple or the most generic? (Melvin Carvalho)
>> 5. Re: Security: multiple or the most generic? (Melanie)
>> 6. Re: Security: multiple or the most generic? (Diva Canto)
>> 7. Re: Security: multiple or the most generic? (Stefan Andersson)
>> 8. Re: Proposal: Drop VS 2005 suppost [Was: C# 3.0 vs .Net 2]
>> (Stefan Andersson)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Mon, 13 Apr 2009 10:37:15 -0700
>> From: Diva Canto <diva at metaverseink.com>
>> Subject: [Opensim-dev] Security: multiple or the most generic?
>> To: opensim-dev at lists.berlios.de
>> Message-ID: <49E3784B.1090001 at metaverseink.com>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> I've been debating with myself and with some ppl in IRC about whether
>> OpenSim should support many security schemes or shoot for the most generic
>> one. Advice appreciated. Here's the situation.
>>
>> There are already 3 different authentication schemes on the pipeline for
>> Teleports, one of them being the current one, and two being on my local
>> non-committed changes. These 3 schemes are: (a) no authentication; (b)
>> session authentication; and (c) key authentication (keys being unique,
>> one-time strings for each client-server pair).
>>
>> (a) is what is currently in place -- hence my nagging about the lack of
>> security in non-VPN'ed grids. But for VPN'ed grids this is perfectly fine.
>> (b) is a weak form of authentication that prevents spoofing from the outside
>> of a grid, but that doesn't prevent spoofing from inside. That is, regions
>> can find out the sessionID of users when they're logged in, and impersonate
>> them. In open grids this is highly unsafe; but in walled-garden grids, this
>> is perfectly fine.
>> (c) is the strongest form, as it allows clients to have a lot more control
>> -- not the raw Linden client, which doesn't quite do that, but others. (c)
>> can also be implemented in the current setup, with the raw Linden client,
>> and with server-side teleports. It's kind of meaningless in this case, but
>> it's no worse than (b) for open grids.
>>
>> So, back to the original question. Should OpenSim support all of these and
>> more, or should we shoot for (c) only?
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Mon, 13 Apr 2009 10:43:40 -0700
>> From: Diva Canto <diva at metaverseink.com>
>> Subject: Re: [Opensim-dev] Security: multiple or the most generic?
>> To: opensim-dev at lists.berlios.de
>> Message-ID: <49E379CC.1020508 at metaverseink.com>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> The corollary being that multiple implies some clever software
>> architecting...
>>
>> Diva Canto wrote:
>>> I've been debating with myself and with some ppl in IRC about whether
>>> OpenSim should support many security schemes or shoot for the most
>>> generic one. Advice appreciated. Here's the situation.
>>>
>>> There are already 3 different authentication schemes on the pipeline for
>>> Teleports, one of them being the current one, and two being on my local
>>> non-committed changes. These 3 schemes are: (a) no authentication; (b)
>>> session authentication; and (c) key authentication (keys being unique,
>>> one-time strings for each client-server pair).
>>>
>>> (a) is what is currently in place -- hence my nagging about the lack of
>>> security in non-VPN'ed grids. But for VPN'ed grids this is perfectly fine.
>>> (b) is a weak form of authentication that prevents spoofing from the
>>> outside of a grid, but that doesn't prevent spoofing from inside. That
>>> is, regions can find out the sessionID of users when they're logged in,
>>> and impersonate them. In open grids this is highly unsafe; but in
>>> walled-garden grids, this is perfectly fine.
>>> (c) is the strongest form, as it allows clients to have a lot more
>>> control -- not the raw Linden client, which doesn't quite do that, but
>>> others. (c) can also be implemented in the current setup, with the raw
>>> Linden client, and with server-side teleports. It's kind of meaningless
>>> in this case, but it's no worse than (b) for open grids.
>>>
>>> So, back to the original question. Should OpenSim support all of these
>>> and more, or should we shoot for (c) only?
>>>
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>>
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Mon, 13 Apr 2009 19:55:09 +0200
>> From: Ideia Boa <ideiaboa at gmail.com>
>> Subject: Re: [Opensim-dev] Security: multiple or the most generic?
>> To: diva at metaverseink.com, opensim-dev at lists.berlios.de
>> Message-ID: <49E37C7D.5050109 at gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Yes and (c)
>>
>> Ideia Boa
>>
>> cumprimentos e boa pascoa Cristina
>>
>> Diva Canto wrote:
>>> I've been debating with myself and with some ppl in IRC about whether
>>> OpenSim should support many security schemes or shoot for the most
>>> generic one. Advice appreciated. Here's the situation.
>>>
>>> There are already 3 different authentication schemes on the pipeline for
>>> Teleports, one of them being the current one, and two being on my local
>>> non-committed changes. These 3 schemes are: (a) no authentication; (b)
>>> session authentication; and (c) key authentication (keys being unique,
>>> one-time strings for each client-server pair).
>>>
>>> (a) is what is currently in place -- hence my nagging about the lack of
>>> security in non-VPN'ed grids. But for VPN'ed grids this is perfectly fine.
>>> (b) is a weak form of authentication that prevents spoofing from the
>>> outside of a grid, but that doesn't prevent spoofing from inside. That
>>> is, regions can find out the sessionID of users when they're logged in,
>>> and impersonate them. In open grids this is highly unsafe; but in
>>> walled-garden grids, this is perfectly fine.
>>> (c) is the strongest form, as it allows clients to have a lot more
>>> control -- not the raw Linden client, which doesn't quite do that, but
>>> others. (c) can also be implemented in the current setup, with the raw
>>> Linden client, and with server-side teleports. It's kind of meaningless
>>> in this case, but it's no worse than (b) for open grids.
>>>
>>> So, back to the original question. Should OpenSim support all of these
>>> and more, or should we shoot for (c) only?
>>>
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>>
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: ideiaboa.vcf
>> Type: text/x-vcard
>> Size: 283 bytes
>> Desc: not available
>> Url :
>> https://lists.berlios.de/pipermail/opensim-dev/attachments/20090413/96150b92
>> /attachment-0001.bin
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Mon, 13 Apr 2009 20:06:07 +0200
>> From: Melvin Carvalho <melvincarvalho at gmail.com>
>> Subject: Re: [Opensim-dev] Security: multiple or the most generic?
>> To: diva at metaverseink.com, opensim-dev at lists.berlios.de
>> Message-ID:
>> <9178f78c0904131106h6f193ac6p7ba130f5b44c3f52 at mail.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> On Mon, Apr 13, 2009 at 7:37 PM, Diva Canto <diva at metaverseink.com> wrote:
>>> I've been debating with myself and with some ppl in IRC about whether
>>> OpenSim should support many security schemes or shoot for the most
>>> generic one. Advice appreciated. Here's the situation.
>>>
>>> There are already 3 different authentication schemes on the pipeline for
>>> Teleports, one of them being the current one, and two being on my local
>>> non-committed changes. These 3 schemes are: (a) no authentication; (b)
>>> session authentication; and (c) key authentication (keys being unique,
>>> one-time strings for each client-server pair).
>>>
>>> (a) is what is currently in place -- hence my nagging about the lack of
>>> security in non-VPN'ed grids. But for VPN'ed grids this is perfectly fine.
>>> (b) is a weak form of authentication that prevents spoofing from the
>>> outside of a grid, but that doesn't prevent spoofing from inside. That
>>> is, regions can find out the sessionID of users when they're logged in,
>>> and impersonate them. In open grids this is highly unsafe; but in
>>> walled-garden grids, this is perfectly fine.
>>> (c) is the strongest form, as it allows clients to have a lot more
>>> control -- not the raw Linden client, which doesn't quite do that, but
>>> others. (c) can also be implemented in the current setup, with the raw
>>> Linden client, and with server-side teleports. It's kind of meaningless
>>> in this case, but it's no worse than (b) for open grids.
>>>
>>> So, back to the original question. Should OpenSim support all of these
>>> and more, or should we shoot for (c) only?
>> (c) is the most important; there is a very well established pattern
>> using SSL, there should also be many libraries for this
>>
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Mon, 13 Apr 2009 20:16:30 +0200
>> From: Melanie <melanie at t-data.com>
>> Subject: Re: [Opensim-dev] Security: multiple or the most generic?
>> To: diva at metaverseink.com, opensim-dev at lists.berlios.de
>> Message-ID: <49E3817E.5050005 at t-data.com>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> Well, if a key is an arbitrary string, then it may also be a
>> constant UUID value, e.g. the standard session id we have now, so
>> (c) really includes (b).
>>
>> Now, my vision of the future 3d internet is that all grids will be
>> walled gardens, trust domains, as an analog to a large, multi-server
>> website. I see people move between those trust domains using the
>> Hypergrid protocol and client side teleporting. I see people use
>> nonlocal messaging (Jabber, etc) instead of local grid comms.
>>
>> Therefore, I believe the ability to run a trust domain with
>> hypergrid ability should be maintained, we should not mandate that
>> all protocols in all cases must assume untrusted regions, because I
>> see those in the hypergrid, rather than the local grid in the future.
>>
>> Hypergridding between these trust domains, I believe, must involve
>> the target domain's user server, which would, in the case of (c),
>> negotiate the key with the viewer.
>>
>> So, for now, (c) is the way to go, just don't forget the (b) use
>> case. Interregion trust should remain possible.
>>
>> Melanie
>>
>>
>> Diva Canto wrote:
>>> I've been debating with myself and with some ppl in IRC about whether
>>> OpenSim should support many security schemes or shoot for the most
>>> generic one. Advice appreciated. Here's the situation.
>>>
>>> There are already 3 different authentication schemes on the pipeline for
>>> Teleports, one of them being the current one, and two being on my local
>>> non-committed changes. These 3 schemes are: (a) no authentication; (b)
>>> session authentication; and (c) key authentication (keys being unique,
>>> one-time strings for each client-server pair).
>>>
>>> (a) is what is currently in place -- hence my nagging about the lack of
>>> security in non-VPN'ed grids. But for VPN'ed grids this is perfectly fine.
>>> (b) is a weak form of authentication that prevents spoofing from the
>>> outside of a grid, but that doesn't prevent spoofing from inside. That
>>> is, regions can find out the sessionID of users when they're logged in,
>>> and impersonate them. In open grids this is highly unsafe; but in
>>> walled-garden grids, this is perfectly fine.
>>> (c) is the strongest form, as it allows clients to have a lot more
>>> control -- not the raw Linden client, which doesn't quite do that, but
>>> others. (c) can also be implemented in the current setup, with the raw
>>> Linden client, and with server-side teleports. It's kind of meaningless
>>> in this case, but it's no worse than (b) for open grids.
>>>
>>> So, back to the original question. Should OpenSim support all of these
>>> and more, or should we shoot for (c) only?
>>>
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>>
>>
>> ------------------------------
>>
>> Message: 6
>> Date: Mon, 13 Apr 2009 11:25:06 -0700
>> From: Diva Canto <diva at metaverseink.com>
>> Subject: Re: [Opensim-dev] Security: multiple or the most generic?
>> To: Melanie <melanie at t-data.com>
>> Cc: opensim-dev at lists.berlios.de
>> Message-ID: <49E38382.8050309 at metaverseink.com>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> Melanie wrote:
>>> Well, if a key is an arbitrary string, then it may also be a constant
>>> UUID value, e.g. the standard session id we have now, so (c) really
>>> includes (b).
>> They are very different. A key is specific for one client-server pair.
>> So for each region the client visits there is a unique key that the
>> other regions might not know about. When TPs are performed on the
>> server-side, this is equivalent to (b) because the regions are acting on
>> behalf of the agent. But for client-side Teleports, this makes all the
>> difference -- the regions don't know about the other regions' keys.
>>
>>> [...]
>>> So, for now, (c) is the way to go, just don't forget the (b) use case.
>>> Interregion trust should remain possible.
>> Right. Even though my main focus is the Hypergrid, I'm a little
>> reluctant in letting go of (b), and even of (a). The problem I'm
>> debating is how to architect OpenSim so that these different schemes can
>> co-exist without the code and configuration being a mess.
>>
>>
>>
>> ------------------------------
>>
>> Message: 7
>> Date: Mon, 13 Apr 2009 21:56:39 +0200
>> From: Stefan Andersson <stefan at tribalmedia.se>
>> Subject: Re: [Opensim-dev] Security: multiple or the most generic?
>> To: <diva at metaverseink.com>, <melanie at t-data.com>
>> Cc: "opensim-dev at lists.berlios.de" <opensim-dev at lists.berlios.de>
>> Message-ID: <BLU134-W413FB4426FB3BE843EC1B7D57F0 at phx.gbl>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>>
>> If we're going to do it 'right' from the start, then obviously, (c) as the
>> general case and (b) as the special case should be the way to go.
>>
>>
>>
>> (Easy for me to say)
>>
>>
>>
>> And on a tangent, I'm closing in on having the AssetServer demanding a
>> connection to a user server to resolve user urls. Thoughts?
>>
>>
>>
>> (It baffles me we don't seem to have that already - I'm not working on the
>> AssetInventory server as I feel its ultimate destiny is still somewhat
>> hazy?)
>>
>> Best regards,
>> Stefan Andersson
>> Tribal Media AB
>>
>>
>>
>>
>>> Date: Mon, 13 Apr 2009 11:25:06 -0700
>>> From: diva at metaverseink.com
>>> To: melanie at t-data.com
>>> CC: opensim-dev at lists.berlios.de
>>> Subject: Re: [Opensim-dev] Security: multiple or the most generic?
>>>
>>> Melanie wrote:
>>>> Well, if a key is an arbitrary string, then it may also be a constant
>>>> UUID value, e.g. the standard session id we have now, so (c) really
>>>> includes (b).
>>> They are very different. A key is specific for one client-server pair.
>>> So for each region the client visits there is a unique key that the
>>> other regions might not know about. When TPs are performed on the
>>> server-side, this is equivalent to (b) because the regions are acting on
>>> behalf of the agent. But for client-side Teleports, this makes all the
>>> difference -- the regions don't know about the other regions' keys.
>>>
>>>> [...]
>>>> So, for now, (c) is the way to go, just don't forget the (b) use case.
>>>> Interregion trust should remain possible.
>>> Right. Even though my main focus is the Hypergrid, I'm a little
>>> reluctant in letting go of (b), and even of (a). The problem I'm
>>> debating is how to architect OpenSim so that these different schemes can
>>> co-exist without the code and configuration being a mess.
>>>
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> https://lists.berlios.de/pipermail/opensim-dev/attachments/20090413/9e21b6e8
>> /attachment-0001.html
>>
>> ------------------------------
>>
>> Message: 8
>> Date: Mon, 13 Apr 2009 23:19:33 +0200
>> From: Stefan Andersson <stefan at tribalmedia.se>
>> Subject: Re: [Opensim-dev] Proposal: Drop VS 2005 suppost [Was: C# 3.0
>> vs .Net 2]
>> To: "opensim-dev at lists.berlios.de" <opensim-dev at lists.berlios.de>
>> Message-ID: <BLU134-W53C0DED1C30553BCD25C6AD57F0 at phx.gbl>
>> Content-Type: text/plain; charset="windows-1252"
>>
>>
>> I have now updated the wiki with the proposal, linking to
>>
>>
>>
>> http://opensimulator.org/wiki/Visual_Studio_2005
>>
>>
>>
>> from the main page. Please read article and add to it.
>>
>>
>>
>> On the page I have stated that 0.6.5 be the last version building on VS
>> 2005. Ideally, I'd like to tag that now, and then introduce a VS 2005
>> 'breaker' to really get things going.
>>
>>
>>
>> Do we have a 0.6.5-rc1 rev?
>>
>> Best regards,
>> Stefan Andersson
>> Tribal Media AB
>>
>>
>>
>>
>>
>>
>> From: stefan at tribalmedia.se
>> To: opensim-dev at lists.berlios.de
>> Date: Thu, 26 Mar 2009 12:32:04 +0100
>> Subject: [Opensim-dev] Proposal: Drop VS 2005 suppost [Was: C# 3.0 vs .Net
>> 2]
>>
>>
>>
>> I propose that
>>
>> "if nobody actually objects on this or the users list before 1st of May
>> 2009, we'll drop VS 2005 support and move on".
>>
>> If I get no strong objections on this, I'll re-post a proposal and update
>> the wiki with the proposal and guidelines to objecting, on friday 3rd of
>> April 2009.
>>
>> Best regards,
>> Stefan Andersson
>> Tribal Media AB
>>
>>
>>
>>
>>
>>
>> Date: Thu, 26 Mar 2009 10:47:21 +0000
>> From: Chris at codetorque.co.uk
>> To: opensim-dev at lists.berlios.de
>> Subject: Re: [Opensim-dev] C# 3.0 vs .Net 2
>>
>>
>>
>>
>>
>> You may find some issues with that since it?s a CTP (pre-beta) from 2006, so
>> some supported syntax in there may have changed for final release, but can?t
>> say for certain.
>>
>> Teravus is correct in that VS2008 is available for free
>> (http://www.microsoft.com/express/vcsharp/). Installing C# 2008 Express you
>> also get SQL Server 2008 Express installed, so you have some options for
>> using that out of the box too. C# Express should be able to handle most
>> basic development tasks ? I guess it just depends on how nice you want to be
>> to 2005 Pro or higher owners going forward as to whether to stay in 2.0 land
>> or move on.
>>
>>
>>
>>
>> From: opensim-dev-bounces at lists.berlios.de
>> [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Stefan Andersson
>> Sent: 26 March 2009 07:45
>> To: opensim-dev at lists.berlios.de
>> Subject: Re: [Opensim-dev] C# 3.0 vs .Net 2
>>
>> Could anybody actually using VS 2005 comment on whether installing the Orcas
>> CTP would solve this?
>>
>> http://www.microsoft.com/downloads/details.aspx?FamilyId=1E902C21-340C-4D13-
>> 9F04-70EB5E3DCEEA&displaylang=en
>>
>> This is the community preview of the C# 3 extensions, made available as an
>> extension to VS 2005.
>>
>> Best regards,
>> Stefan Andersson
>> Tribal Media AB
>>
>>
>>
>>
>>> Date: Thu, 26 Mar 2009 01:27:42 -0400
>>> From: teravus at gmail.com
>>> To: opensim-dev at lists.berlios.de
>>> Subject: Re: [Opensim-dev] C# 3.0 vs .Net 2
>>>
>>> Our issue here isn't mono support :) Mono has 3.0 support since
>>> 1.9.1. It's our support of Visual Studio 2005 as a build tool.
>>>
>>> Visual Studio 2005 is the tool that doesn't understand code in C# 3.0 :).
>>>
>>> Visual Studio 2008 will generate a 2.0 assembly from 3.0 code.
>>> Visual Studio 2005 will fail to build.
>>>
>>> As far as I really know.. the only reason to support Visual Studio
>>> 2005 right now is for people who have Visual Studio 2005 Standard,
>>> Pro, or Team licenses. Visual Studio 2008 Express is freely
>>> downloadable and available and Mono is quite happy with 3.0 syntax
>>>
>>> Sincerely
>>>
>>> Teravus
>>>
>>> On 3/26/09, Frisby, Adam <adam at deepthink.com.au> wrote:
>>>>
>>>>
>>>> If we consider a shift to .NET 3, I?d like to also propose utilizing the
>> new
>>>> Socket members that .NET 3 introduced ? there is some in there for high
>>>> performance ASync socketing which perform significantly better than
>> previous
>>>> ones in the kinds of situations we employ.
>>>>
>>>>
>>>>
>>>> (As long as Mono 2.0.2 has those implemented of course ? but it
>> shouldn?t be
>>>> hard for the, they could at least just make them a splint to the old
>>>> methods)
>>>>
>>>>
>>>>
>>>> Adam
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> From: opensim-dev-bounces at lists.berlios.de
>>>> [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of
>>>> Ruud Lathrop
>>>> Sent: Wednesday, 25 March 2009 11:34 AM
>>>> To: opensim-dev at lists.berlios.de
>>>> Subject: Re: [Opensim-dev] C# 3.0 vs .Net 2
>>>>
>>>>
>>>>
>>>>
>>>> Visual Studio 2005 is using .NET 2.0/C# 2, only with some extending can
>> you
>>>> use some .NET 3/C# 3 features (WCF is the best known).
>>>>
>>>> It seems that Visual Studio 2008 is doing some tricks for you when you
>> have
>>>> a .NET 2.0 project, but use .NET 3/3.5 syntax. Like this:
>>>>
>>>> public string Test { get; set; }
>>>>
>>>> Just works in a .NET 2.0 project, same with lambda, while it is .NET 3/
>> C# 3
>>>> specs
>>>>
>>>> Ruud
>>>>
>>>>
>>>>
>>>> On Wed, Mar 25, 2009 at 3:57 PM, Teravus Ovares <teravus at gmail.com>
>> wrote:
>>>> The problem with Lamda Expressions isn't compiling to IL 2.0.. it's
>>>> compiling in Visual Studio 2005. Visual Studio 2005 will not compile
>>>> Lamda Expressions at all.
>>>>
>>>> Regards
>>>>
>>>> Teravus
>>>>
>>>>
>>>>
>>>> On 3/25/09, Sean Dague <sdague at gmail.com> wrote:
>>>>> Stefan Andersson wrote:
>>>>>> Yo.
>>>>>> =20
>>>>>> =20
>>>>>> =20
>>>>>> Feeling a bit stupid here, but just realized that many C# 3.0
>> features =
>>>>> (lambda expressions and inferred types, for example) compiles just
>> fine t=
>>>>> o the .Net 2 IL, so in practise, it can be used if the installed csc
>> supp=
>>>>> orts it.
>>>>>> =20
>>>>>> =20
>>>>>> =20
>>>>>> What I'm saying is that we can probably start using some C# 3.0
>> feature=
>>>>> s already even on mono (I guess) without moving from .Net 2.0.
>> Question i=
>>>>> s, what features?
>>>>>> =20
>>>>>> =20
>>>>>> Could any mono person have a look at what C# 3.0 constructs are
>> actuall=
>>>>> y backwards compatible with .Net 2.0 on mono?
>>>>>
>>>>> One approach would be to make a new unit test that used some of those
>>>>> features, then it would be easy for people to test with their
>>>>> environment. I suspect mono 1.9.1 is still going to have issues, and
>> we
>>>>> haven't committed to dumping it yet (as that's what is shipping in the
>>>>> latest stable release of Ubuntu, which a lot of people are using).
>>>>>
>>>>> The new Ubuntu release comes out in April with Mono 2.0.2, so we can
>>>>> leave 1.9.1 behind in the near future.
>>>>>
>>>>> -Sean
>>>>>
>>>>> --=20
>>>>> Sean Dague / Neas Bade
>>>>> sdague at gmail.com
>>>>> http://dague.net
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Opensim-dev mailing list
>>>>> Opensim-dev at lists.berlios.de
>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Opensim-dev mailing list
>>>> Opensim-dev at lists.berlios.de
>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> Opensim-dev mailing list
>>>> Opensim-dev at lists.berlios.de
>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>>
>>>>
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-devNo virus found in
>> this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 8.0.238 / Virus Database: 270.11.22/2015 - Release Date: 03/24/09
>> 16:00:00
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> https://lists.berlios.de/pipermail/opensim-dev/attachments/20090413/4939029b
>> /attachment.html
>>
>> ------------------------------
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>> End of Opensim-dev Digest, Vol 20, Issue 35
>> *******************************************
>>
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
More information about the Opensim-dev
mailing list