[Opensim-dev] Perl vs C# UGAI?

Charles Krinke cfk at pacbell.net
Thu Apr 3 14:11:46 UTC 2008


Gentlemen:

The reason I brought this up in the first place is that 3 respected members of our community approached me about changing OSGrid to run the Perl UGAI. So, I have spent several hours in the last 3 days discussing this in PM.

I was feeling a bit like I was holding the project back, but, putting on my OSGrid hat for a moment, the issues appear to be:

1) Adding a second or new UGAI has the potential to write dissimilar data into the mysql database on OSGrid and cause things to break in new and mysterious ways.

2) It stands the high probability of loosing testing credibility with core with reports if we are not using the existing UGAI.

3) I can see things not working with the Perl UGAI that might tend to cause undue extra work to debug if OSGrid runs the Perl UGAI.

4) It seems experimental and incomplete in glancing at it, but I also am not a Perl programmer.

So, my desire is to have OSGrid provide the very best feedback to core to allow us to move forward as quickly as possible. And with that said, I desire to follow Mw & Lbsa's lead and leave OSGrid as it is.

Charles

----- Original Message ----
From: Michael Wright <michaelwri22 at yahoo.co.uk>
To: opensim-dev at lists.berlios.de
Sent: Thursday, April 3, 2008 5:29:57 AM
Subject: Re: [Opensim-dev] Perl vs C# UGAI?

Yes the aim of opensim is to have a set of protocols and API, that is stable. But we are no where near that point yet. The grid procotols need to change, they have been on our roadmap to change for months now. And by having two versions of the UGAI in two different languages in svn, makes doing changes a lot harder. We can't say that current API's/protocols are stable as they are now, a lot still needs to change. So we need to make sure there aren't extra things stopping those changes.


James Stallings II <james.stallings at gmail.com> wrote: I think it highly desirable to envision the opensim project in the terms that lulurun has used; to paraphrase, a set of protocols and an associated API.

I for one am delighted to see implementations in alternate languages coming to the fore; c# has been shown to be anything but optimal for this application area (IMHO) and alternatives are beneficial in a variety of ways, from providing practical alternatives to performance baselines.
 
I am so committed to this notion that I have undertaken the study of Erlang in the interest of creating an implementation of opensim in that language, which in my estimation is a far more suitable implementation language than either perl or c#.
 
This of course represents only my personal perspective, and perhaps only incidentally that of a few others; and while what is a solution for me or lulurun is not necesarily the solution for everyone, every effort should be made to encourage such efforts in the interest of providing options to the implementor of regions and grids.
 
At the very least, every effort should be made not to discourage such projects.

For me, I say leave the perl code right where it is, and embrace this turn of events with the same sort of technical vigor and optimism that has been typical of this project in the past.
 
Just my 0.02$L

Cheers,
daTwitch


On Thu, Apr 3, 2008 at 7:28 AM, Melanie <melanie at t-data.com> wrote:
 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
 _______________________________________________
 Opensim-dev mailing list
 Opensim-dev at lists.berlios.de
 https://lists.berlios.de/mailman/listinfo/opensim-dev
 





-- 
===================================
The wind
scours the earth for prayers
The night obscures them _______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

 
      
Sent from Yahoo! Mail.
A Smarter Inbox.

-----Inline Attachment Follows-----

_______________________________________________
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: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080403/f1c927eb/attachment-0001.html>


More information about the Opensim-dev mailing list