<div>I start this letter by saying, I respect John and I agree on type standardization being important. </div>
<div> </div>
<div>Having said that, I disagree that the libomv types are the types to standardize on. Essentially what this means is we will be bringing libomv/libsecondlife /back/ into the core parts of opensimulator. It's my understanding that we've spent countless hours trying to eliminate reliance on the library so that we are insulated from the breaking changes that we invariably see in libomv/libsecondlife between versions.</div>
<div> </div>
<div>Also, to the 'trademark changes'... no, we adopted this approach before all of the 'trademark related' changes. We adopted this around LibSecondLife Revision 1550. There were 3 non trademark breaking changes between the previous release version and this revision. There was one breaking change between Revision 1450 and revision 1550. Two of those breaking changes were subtle, meaning the compiler wouldn't notify you that something nasty happened. I'll list the changes here for brevity;</div>
<div> </div>
<div>1. LLUUID, LLVector3, and LLQuaternion were no longer serializable. Base types *MUST* be serializable for Grid communications to work. (Silent and nasty) (took approximately 8 man hours to resolve)</div>
<div> </div>
<div>2. LLUUID.ToString() changed from the non dashed format to the dashed UUID format. I still gawk when I think about this change. The number of applications that were rendered completely useless by this change were many(select regionlocation from regions where RegionID='65e44815-6d70-4746-abaf-7a5f32272308' does not work if all of the data is stored '65e448156d704746abaf7a5f32272308'. (Silent and nasty) (took approximately 48 man hours to resolve)</div>
<div> </div>
<div>3. In addition, several packet identification methods that we use extensively were removed. (took approximately 2 man hours to resolve)</div>
<div> </div>
<div>Remember this is just *one* library update that all of this occurred on. I know MW and lbsa have stories about extreme issues with previous libsecondlife updates. (Caps, asset upload, XML format changes, TextureEntry changes, LLColor changes.. You name it, it's been a problem).</div>
<div> </div>
<div>All in all, I'm 'seriously' suggesting that OpenSimulator maintain a set of base types that the project controls, or is in a dedicated library that is completely stable (Obviously not LibOMV/LibSecondLife). Otherwise, somewhere down the line a LibOMV update will come that will cause OpenSimulator to fail and the devs will throw their arms up in frustration at the complete and utter arrogance that the libsecondlife project has shown of the effect API changes have on the users. </div>
<div> </div>
<div>In IRC chat, you mentioned something along the lines of 'people must be waiting for someone else to do it' implying that the opensimulator devs are lazy.</div>
<div> </div>
<div>This is not laziness, this is an attempt to avoid being masochistic.</div>
<div> </div>
<div>Best Regards</div>
<div> </div>
<div>Teravus</div>
<div><br> </div>
<div><span class="gmail_quote">On 8/8/08, <b class="gmail_sendername">Frisby, Adam</b> <<a href="mailto:adam@deepthink.com.au">adam@deepthink.com.au</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div lang="EN-AU" vlink="purple" link="blue">
<div>
<p><span style="FONT-SIZE: 11pt; COLOR: #1f497d">I can +1 these patches in principle.</span></p>
<p><span style="FONT-SIZE: 11pt; COLOR: #1f497d"> </span></p>
<p><span style="FONT-SIZE: 11pt; COLOR: #1f497d">It's the 'in practice' that will need some fiddling as changing this many data types all at once is likely to cause an incredible amount of fun debugging later. (and will also mandate every grid update every region as our remoting support will break as a guarantee)</span></p>
<p><span style="FONT-SIZE: 11pt; COLOR: #1f497d"> </span></p>
<p><span style="FONT-SIZE: 11pt; COLOR: #1f497d">Regards,</span></p>
<p><span style="FONT-SIZE: 11pt; COLOR: #1f497d"> </span></p>
<p><span style="FONT-SIZE: 11pt; COLOR: #1f497d">Adam</span></p>
<p><span style="FONT-SIZE: 11pt; COLOR: #1f497d"> </span></p>
<div style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: medium none">
<div>
<div style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: #b5c4df 1pt solid; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
<p><b><span lang="EN-US" style="FONT-SIZE: 10pt">From:</span></b><span lang="EN-US" style="FONT-SIZE: 10pt"> <a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:opensim-dev-bounces@lists.berlios.de" target="_blank">opensim-dev-bounces@lists.berlios.de</a> [mailto:<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:opensim-dev-bounces@lists.berlios.de" target="_blank">opensim-dev-bounces@lists.berlios.de</a>] <b>On Behalf Of </b>Charles Krinke<br>
<b>Sent:</b> Friday, 8 August 2008 1:55 PM<span class="q"><br><b>To:</b> <a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:opensim-dev@lists.berlios.de" target="_blank">opensim-dev@lists.berlios.de</a><br>
</span><b>Subject:</b> Re: [Opensim-dev] Standardizing types in OpenSim</span></p></div></div>
<div><span class="e" id="q_11ba42189a71dde8_3">
<p> </p>
<div>
<div>
<p><span>Well, I'll merely say that I have the highest of respect for jhurliman's opinion and what he says here seems like a set of reasonable ideas.<br><br>Charles</span></p></div>
<div>
<p><span> </span></p>
<div>
<p><span style="FONT-SIZE: 10pt">----- Original Message ----<br>From: "Hurliman, John" <<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:john.hurliman@intel.com" target="_blank">john.hurliman@intel.com</a>><br>
To: <a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:opensim-dev@lists.berlios.de" target="_blank">opensim-dev@lists.berlios.de</a><br>Sent: Friday, August 8, 2008 11:44:59 AM<br>Subject: [Opensim-dev] Standardizing types in OpenSim<br>
<br>Hello list,<br><br>This is my first e-mail to opensim-dev so I'll start with an<br>introduction. I'm an engineer at Intel researching scalable models for<br>virtual worlds. A lot of the research will revolve around open,<br>
user-generated content models like Second Life and OpenSim. I'm also the<br>primary developer of libOpenMetaverse (formerly libsecondlife, still<br>located at <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://www.libsecondlife.org/" target="_blank">http://www.libsecondlife.org/</a> for the time being).<br>
<br>I've spent some time looking at the lower level components of OpenSim<br>and have a patch to propose. The basic type objects (vector, quaternion,<br>rays, etc) are spread out and duplicated over several internal classes<br>
and external libraries. There are at least five different types of<br>Vector3, multiple quaternion and matrix classes, etc. Some of these are<br>classes instead of structs, meaning a basic operation like subtracting<br>two vectors and putting the result in a third creates several new<br>
objects on the heap that the garbage collector has to track. I believe<br>this is responsible for a lot of the heavy memory and garbage collector<br>activity I am seeing. There is also a lot of duplicated code which has<br>
led to incorrect constructors (such as new Vector3(x, y, y)) and makes<br>things more difficult to unit test.<br><br>The OpenMetaverse library has a set of types useful to virtual worlds<br>that have been in development for two years and implement all of the<br>
functionality needed in OpenSim. I've created a very large patch that<br>upgrades OpenSim from libsecondlife to the latest libOpenMetaverse,<br>drops Axiom, and uses the built-in libomv types wherever possible. There<br>
are a few places that I have skipped over for now to avoid introducing<br>too many moving parts in a single patch: BulletX still uses Mono.Xna,<br>and Meshmerizer still uses PhysicsVector/Vertex/Triangle.<br><br>I've spoken with some of the OpenSim developers about problems keeping<br>
up with libsecondlife changes. The major changes happened to prevent a<br>trademark conflict with Linden Lab, and also establish libopenmv as a<br>generalized platform for building virtual worlds instead of a library to<br>
connect to Linden Lab's servers. I think this patch is an important move<br>in that direction, and to prevent any future headaches I'm volunteering<br>to maintain the OpenSim->libOpenMetaverse dependency in the event of any<br>
API changes.<br><br>I'm working on grid mode compatibility testing (sandbox mode appears to<br>work fine) and will have the patch on Mantis early to mid next week. So<br>far the patch itself weighs in around 1.7MB plus binaries. Twenty<br>
revisions have passed since I initially wrote it and maintaining it<br>against the latest SVN can be time consuming, so I wanted to kick start<br>with this e-mail before posting the patch.<br><br>John Hurliman<br>_______________________________________________<br>
Opensim-dev mailing list<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br><a onclick="return top.js.OpenExtLink(window,event,this)" href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a></span></p>
</div></div></div></span></div></div></div></div><br>_______________________________________________<br>Opensim-dev mailing list<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a onclick="return top.js.OpenExtLink(window,event,this)" href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br><br></blockquote></div><br>