<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>One aspect is that we need to foster a spawning culture; we can't have one project that everybody's trying to add to to it make suit everybodys need; that's just not how internet development works.<BR>
<BR>
We need to get people to publish code on their own wikis, spawn separate sourceforge or berlios projects; an we will link to them, recommend some, even have some official add-on repository (think firefox)<BR>
<BR>
but the CORE repository has to be focused on one thing, and one thing only: Getting a WORKING, TIGHT, STABLE reference implementation of a set of MODULAR SERVICES and STANDARD PROTOCOLS.<BR><BR>
I think we're approaching our limit for how much code should be in that CORE repository. From now on, we need to spawn spin-offs.<BR>
<BR>/Stefan<BR><BR><BR>
<HR id=stopSpelling>
<BR>
> From: brianw@terrabox.com<BR>> To: opensim-dev@lists.berlios.de<BR>> Date: Thu, 3 Apr 2008 11:30:50 -0500<BR>> Subject: Re: [Opensim-dev] Perl vs C# UGAI?<BR>> <BR>> I couldn't agree more.<BR>> <BR>> My personal view of a project like OpenSim is that it is a reference<BR>> implementation of the OpenSim protocol(s). As such, it shouldn't concern<BR>> itself with containing every single implementation of the various<BR>> servers. <BR>> <BR>> I really like the idea of having a wiki page listing "OpemSim Protocol<BR>> based Projects" that end users can pick from. the opensimulator.org<BR>> website could focus on protocol specifics, and linking to specific<BR>> implementations with the core C# implementation downplayed as just a<BR>> reference implementation that may or may not be as stable or fast as 3rd<BR>> party implementations and utilities.<BR>> <BR>> This would also make it possible for us to take the add-in modules like<BR>> the recent bad behaving interface demo module and keep them in a<BR>> seperate "official add-ons" repository that people can overlay on the<BR>> core report. How that overlay is acheived can be worked out later. ;)<BR>> <BR>> I have to agree with Charles on the OSGrid concerns. I say leave it<BR>> using just the C# core reference implementation so it's a solid known<BR>> setup to test against. If we really want to semi-officially suport the<BR>> alternatives, then OSGrid can negotiate hosting of secondary testing<BR>> grids with the various implementations if the alternative creator<BR>> doesn't have a place to run their servers (I'm making an assumption of<BR>> resource availability here, which may or may not be possible).<BR>> <BR>> On Thu, 2008-04-03 at 10:04 -0400, Sean Dague wrote:<BR>> > On Thu, Apr 03, 2008 at 02:27:07PM +0100, Justin Clark-Casey wrote:<BR>> > > I'm very much in favour of the idea of alternative implementations of <BR>> > > the UGAI protocols.<BR>> > > <BR>> > > As James, has suggested, in other circumstances it would be good to <BR>> > > formally write down the protocol and advertise and discuss changes <BR>> > > beforehand. However, the problem is, as Michael and Sean say, is that <BR>> > > it's still in a state of considerable flux (this is Alpha code!). Trying <BR>> > > to formalize at this stage would considerably slow down development.<BR>> > > <BR>> > > I have to agree with Michael that we shouldn't have alternative <BR>> > > implementations in our own svn tree - it will cause considerable <BR>> > > confusion as to what OpenSim officially supports and what it doesn't. <BR>> > > And hypothetically, if Lulurun goes away for whatever reason <BR>> > > (hypothetically!) the onus to maintain it as an 'official' alternative <BR>> > > would fall on the OpenSim developers. Whether the Perl alternative <BR>> > > should really be the reference (not necessarily the best) implementation <BR>> > > is another argument, I think. I can see pros and cons for both.<BR>> > > <BR>> > > Having said that, it sounds like Lulurun is willing to maintain the code <BR>> > > to match changes in the protocol. Even if the code doesn't live inside <BR>> > > the OpenSim tree, I believe we could make an effort on an informal basis <BR>> > > to advertise and discuss proposed protocol changes before the fact <BR>> > > (unless the changes are very large, in which case things would have to <BR>> > > be done post-facto).<BR>> > <BR>> > Yes, we should have links to alternate implementations somewhere on the<BR>> > wiki. Honestly, I suspect that we'll end up with UGAI in at least perl,<BR>> > python, ASP.NET, java, and ruby by the end of the year that people are<BR>> > maintaining. That is a strength, not a weakness.<BR>> > <BR>> > -Sean<BR>> > <BR>> > _______________________________________________<BR>> > Opensim-dev mailing list<BR>> > Opensim-dev@lists.berlios.de<BR>> > https://lists.berlios.de/mailman/listinfo/opensim-dev<BR>> <BR>> _______________________________________________<BR>> Opensim-dev mailing list<BR>> Opensim-dev@lists.berlios.de<BR>> https://lists.berlios.de/mailman/listinfo/opensim-dev<BR><BR></body>
</html>