<div dir="ltr">Hey,<div><br></div><div> I would agree it is a challenge to make module for open sim when the innards are undocumented and ever in flux. Took me a while to resolve an issue that gave no errors, but did not give me any results when we moved from .7 to .8 code base. The next best things to an API is put internal documentation to what a function is used for and maybe a comment or two on how it it used. </div><div><br></div><div> A case in point(one of the projects that mysteriously broke) I had a region module that when a new avatar entered the region , it would check its agee and then send a group message out to group. I tracked it down to the call to post the message, it took probably 3 hours of trial and errors to get it back working, just by altering the values a little. But it still does not work like it did before, I just wrote it off to some check that was added to prevent an avatar from from sending a message to a group they are not members of. Might of been the root of the issue I was having but even wh debug logging turned on I could not get any indication that the it was failing or even working. But now it back working at useful level tho. I did tho get the bases for the code from one of justins blogs I believe. </div><div><br></div><div> But here is very little documentation to go on. Or even simple examples. But i understand allot of the reasons why. But one thing to think about tho, most programmers hate to read other people code to begin with. And if they find it to hard to understand why it done this way they will attempt to reinvent the wheel. I find the learning curve for the code is steep and ever changing. This is why I stick with a stable version and not update tell I think it worth the hassles of it. I just upgrading from 0.8 to 0.8.0.3 ...</div><div><br></div><div>But with that said, you guys doing great work. </div><div><br></div><div><br></div><div> </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 9, 2014 at 1:49 PM, Mic Bowman <span dir="ltr"><<a href="mailto:cmickeyb@gmail.com" target="_blank">cmickeyb@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I will say that i got burned again on interface changes last week (changes to the thread watchdog and monitors). <div><br></div><div>My concern is not that the interface is changing (I expect that since I'm tracking master), but that there doesn't seem to be a good way to accommodate "old code". Basically, once you make the change to the interface, I'm kind of forced to either deal with compatibility across multiple versions of my code (which given the challenges of conditional compilation in C# really means managing multiple branches of the code that track different opensim versions), or just sacrifice any backwards compatibility (or move the dispatcher code into core which means that it becomes "our" problem to fix it when a change happens). And we're not talking about obscure public methods, but thread management. </div><div><br></div><div>No, I don't have a suggestion for improving the situation other than to preserve old interfaces & mark them deprecated and only remove the deprecated methods on major releases.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>--mic</div><div><br></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 9, 2014 at 10:41 AM, Justin Clark-Casey <span dir="ltr"><<a href="mailto:jjustincc@googlemail.com" target="_blank">jjustincc@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">From my perspective, OpenSimulator is a young and complex project that has grown organically, in an area where there is very little previous knowledge to draw upon and better ways to do things are frequently discovered (e.g. the change in service approach between 0.6.9 and 0.7). This has been the case since the project's beginnings and is still very much true today.<br>
<br>
In such an environment, I think it would be a big mistake to try to arbitrarily freeze or restrain internal change. It would make it far harder for those of us actively working on core to fix issues and evolve the codebase for long-term sustainability. In this, I very much agree with the Linux approach [1] where drivers (modules) outside of the core simply have to adapt to internal changes. Just because a method is made public in C# (which is necessary for projects to call each other) does not make in an API.<br>
<br>
That said, to take the Linux example further, there are proper agreed upon external facing APIs (POSIX, etc.) that are preserved whenever possible. I have no objection if someone wants to create and post a document proposing actual API(s) that go through a proper design and criticism process. Indeed, the reason why it can be difficult for region modules is because of the very large amount of inconsistency and occasional bizarreness of the internal code, something that I would not want to see frozen in place.<br>
<br>
However, I personally think it is much too early for such API creation and it is not something I would initiate.<br>
<br>
The current effective QA/testing process is to make a change to master and then get feedback from people using that branch. As programmer labour is scarce and often unpaid, there is no manpower available for any other approach.<br>
<br>
[1] <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/stable_api_nonsense.txt" target="_blank">https://git.kernel.org/cgit/<u></u>linux/kernel/git/torvalds/<u></u>linux.git/tree/Documentation/<u></u>stable_api_nonsense.txt</a><span><br>
<br>
On 09/12/14 17:56, Michael Heilmann wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Opensim Developers<br>
<br>
On the MOSES grid we have been attempting to profile and test the Opensimulator code for quite a bit. I saw the unit<br>
tests that already exist, also that Opensim has a Jenkins process running against the repository. I also saw the<br>
conversation concerning API's and Justin renaming a function. Has there been any thought into segregating Opensimulator<br>
components and creating API's for the different components?<br>
<br>
I am working on an After Action Review region module, where user actions are recorded on command, and later re-enacted<br>
using the NPC module on command. This is pretty hairy with the number of classes from different parts of the code I've<br>
instantiated and interfaced with to get some of the behaviour I am seeking for the module.<br>
<br>
A clear API would make both testing/benchmarking simpler, as well as module development. The tight coupling and<br>
functionality crossing multiple namespaces should also become clear as the API progresses. A clear delineation between<br>
the networking, scripting, and physics components would allow for better independent testing and development of each<br>
component. Thoughts?<br>
<br>
While I've breached the subject of instrumenting and testing Opensimulator, has anyone thought about a testing/QA<br>
process on Opensim?<br>
<br>
</blockquote>
<br>
<br>
-- <br></span>
Justin Clark-Casey (justincc)<br>
OSVW Consulting<br>
<a href="http://justincc.org" target="_blank">http://justincc.org</a><br>
<a href="http://twitter.com/justincc" target="_blank">http://twitter.com/justincc</a><div><div><br>
______________________________<u></u>_________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@opensimulator.org" target="_blank">Opensim-dev@opensimulator.org</a><br>
<a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">http://opensimulator.org/cgi-<u></u>bin/mailman/listinfo/opensim-<u></u>dev</a><br>
</div></div></blockquote></div><br></div>
</div></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" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
<br></blockquote></div><br></div>