<div dir="ltr"><div><div><div><div>On point 2, the coding standards are pretty much the C# guidelines at [1] (I thought there used to be a longer doc but can't find it on a quick google).<br><br></div>On point 3, this is very true.  It's a problem of the codebase having grown organically with many different developers of varying skill levels.<br><br></div>During the 2013 and 2014 OSCC conferences I spent a lot of time on scalability but much of this was ad-hoc fixes or measurement tooling.  The advantage of being extremely thread happy is that if one thread gets blocked (e.g. waiting on I/O) then this won't halt other threads (assuming it isn't in a locked region).  But the disadvantage is unpredictable performance and overhead though I don't know how much.<br><br></div>I believe any VW engine eventually need something like an OS scheduler to control work performance and make sure that CPU utilization is efficient and handles degradation gracefully at 100% utilization.  However, that's an extremely tough problem and I'm not sure it's even possible in a managed language.<br><br></div><div>On point 4, I believe any future is gradual evolution.  The investment required for radical change is simply too high.  Perhaps it would be easier if some way can be found to break apart monolithic VW systems but then monoliths have continued to win in the operating system space (Linux vs micro-kernels for instance) and I think operating systems have many similarities with user script executing virtual worlds.<br><br></div><div>-- Justin<br></div><div><br></div>-- Justin<br><div><div><div><div><div><br>[1] <a href="https://msdn.microsoft.com/en-us/library/ff926074.aspx">https://msdn.microsoft.com/en-us/library/ff926074.aspx</a><br></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 13, 2015 at 5:32 PM, Cinder Roxley <span dir="ltr"><<a href="mailto:cinder@alchemyviewer.org" target="_blank">cinder@alchemyviewer.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">On August 13, 2015 at 8:14:30 AM, Maxwell, Douglas CIV USARMY ARL (US) (<a href="mailto:douglas.maxwell3.civ@mail.mil" target="_blank">douglas.maxwell3.civ@mail.mil</a>) wrote:</div> <div><blockquote type="cite" style="color:rgb(0,0,0);font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span><div><div></div><div>Classification: UNCLASSIFIED<span> </span><br>Caveats: NONE<span> </span><br><br>Can someone explain to me why the core developers insist on control of the<span> </span><br>code, but refuse to manage the project? I ask again: what are your plans for<span> </span><br>the future of Open Simulator? It's ok to say you don't have any, let's make<span> </span><br>some!<span> </span><br><br>I'll throw out some ideas based on the MOSES goals and objectives:<span> </span><br><br>1) Scale limitations lifted. We need a system that is governed by its<span> </span><br>available hardware and network resources, not bound by software limits.<span> </span><br><br>2) Let's create clear definitions of "stability".<span> </span><br><br>3) Clear and up-to-date API documentation.<span> </span><br><br>4) Clear and up-to-date OS deployment guidance under numerous typical network<span> </span><br>topologies.<span> </span><br><br>5) Bug identification & reduction.<span> </span><br><br>6) Efficient ray tracing. Useful for simulation of sensors as well as<span> </span><br>naturalized bot interactions.<span> </span><br><br>7) N-body physics. Would be nice to have vehicles that can follow terrain<span> </span><br>and not look like Star Wars land speeders. Would also be nice to have more<span> </span><br>natural avatar movement rather than the rigid animations we use now.<span> </span><br><br>What are yours? Anyone?<span> </span><br><br>v/r -doug</div></div></span></blockquote></div><p>This can be considered my “wish list” as I don’t really have a say in what happens, but I’m willing to put in a fair share of work in seeing that it can be done if others agree these are desirable targets:</p><p>1) Restating what Doug has mentioned, Clear and up-to-date API documentation. This hinders contributors, myself included, from working on things and leads to a lot of frustration and disappointed from well-intentioned folks.</p><p>2) A coding standard that defines and formalizes the style of code used throughout the codebase and is adhered to and enforced and should be pointed to often and regularly for contributions. Good code is easy to read and manageable. A formal coding standard is a good step in that direction.</p><p>3) OpenSim is a thread monster. There doesn’t seem to be any sort of approach to how threading is handled. This I think would fall under Doug’s criteria for #1.</p><p>4) I think it’s time to hop off the fence and decide whether to maintain the Second Life protocol compatibility, (Which, let’s be honest, is pretty lacking. There’s a lot missing post-2010.) or to break new ground. Linden Lab has apparently made their decision regarding that. There are viewer developers out there willing to work with OpenSimulator is doing this. I am one of them. I just can’t be in IRC all the time, but I want to do this with you guys and I know there are others out there willing to put in the work to build clients to connect to new and better worlds with sensible protocols.</p><p>Please don’t take any of this as criticism as it is not meant as such. I appreciate all the work that everyone on this project and who is affiliated with it does.</p><span class="HOEnZb"><font color="#888888"><div><div style="font-family:helvetica,arial">-- <br>Cinder Roxley<br>Sent with Airmail</div></div></font></span></div><br>_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
<a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" rel="noreferrer" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
<br></blockquote></div><br></div>