[Opensim-dev] Perl vs C# UGAI?

Melanie melanie at t-data.com
Thu Apr 3 12:28:19 UTC 2008


Hi,

to me, the apache-based UGAI seems like a light at the end of the 
tunnel, finally there is a way to create a UGAI that is not all 
custom stuff, where one bad request can't kill the grid dead, where 
restarting is easy, and load balancing is, as well.

Taking it out of SVN means relegating it to a backseat, where 
changes in it can be made by only it's creator. Developer feedback 
would be low to nonexistent. It would totally preclude it becoming 
the "standard" UGAI, replacing the C# ones.

I say, leave it in there and let people vote with their feet! I 
never felt comfortable with the C# UGAI, and I'm happy this has 
finally appeared.

Some here have written alternative UGAI, but never much publicized 
that. Now someone does, and it sparks up a whole big controversy.
Some people don't trust the C# UGAI, so why is there a desire to 
make it appear that those are the only option?

Melanie


Michael Wright wrote:
> One problem with having two sets of UGAI is that it makes changes harder to do. As I'm not really a perl programmer, if I was going to doing a change to something in the grid servers or the protocol. It would mean I either had to change the perl ones too or break those. And as they are in our svn, we would most likely getting people complaining they are broke. And this is a big factor in my mind as over the next few weeks there is a chance that I will be able to do some work on the grid servers/protocols.
> 
>  I'm with Stefan on this one, in that I'm all for there being different implementations of the UGAI's but think for now we should only have one in the svn other wise it is just going to lead to confusion/problems if one implementation is broke because of some change to the other. So think other implementations should be outside the svn. 
> 
> We do understand that not everyone wants to use the standard c# versions (and to be fair, who would? with the general state they are in). Thats why we (myself and Stefan) have wrote our own ASP version of some of the backend servers, but we haven't added them to the svn for the reasons I gave above. In that not everyone would want to run ASP servers, so we think at this time at least there should only be one version in svn. So that people aren't affraid to do changes in them, like they could be if they knew that there was other versions in svn that they were breaking by doing those changes. 
> 
> Stefan Andersson <stefan at tribalmedia.se> wrote:    .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma }  Simple and straight answer: "No."
>   
>  Also, the whole 'share' dir should be externalized into some other repository, or just a (set of) downloadable tarball(s) on the wiki, ASAP
>   
>  /Stefan
> 
> 
> 
>   
> ---------------------------------
>  Date: Wed, 2 Apr 2008 20:02:52 -0700
> From: cfk at pacbell.net
> To: opensim-dev at lists.berlios.de
> Subject: [Opensim-dev] Perl vs C# UGAI?
> 
>    .ExternalClass DIV {;}     I am really puzzled about this new Perl UGAI and it leads to a number of questions:
> 
> Are we going to have two sets of servers for grid mode? One written in C# and the other written in Perl?
> 
> Will we have each of them with the same features? Will we abandon the C# UGAI servers? 
> 
> How will we seperate out issues between regions on a grid and the grid servers if some grids run with Perl UGAI and some run with C# UGAI?
> 
> Charles
> 
> 
> 
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 
> 
>        
> ---------------------------------
>  Yahoo! for Good helps you make a difference
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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