[Opensim-dev] Profiling and an API between Opensim components

[Mic Bowman]

I will say that i got burned again on interface changes last week (changes
to the thread watchdog and monitors).

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.

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.

--mic


On Tue, Dec 9, 2014 at 10:41 AM, Justin Clark-Casey <
jjustincc at googlemail.com> wrote:

> 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.
>
> 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.
>
> 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.
>
> However, I personally think it is much too early for such API creation and
> it is not something I would initiate.
>
> 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.
>
> [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/
> linux.git/tree/Documentation/stable_api_nonsense.txt
>
> On 09/12/14 17:56, Michael Heilmann wrote:
>
>> Opensim Developers
>>
>> On the MOSES grid we have been attempting to profile and test the
>> Opensimulator code for quite a bit.  I saw the unit
>> tests that already exist, also that Opensim has a Jenkins process running
>> against the repository.  I also saw the
>> conversation concerning API's and Justin renaming a function.  Has there
>> been any thought into segregating Opensimulator
>> components and creating API's for the different components?
>>
>> I am working on an After Action Review region module, where user actions
>> are recorded on command, and later re-enacted
>> using the NPC module on command.  This is pretty hairy with the number of
>> classes from different parts of the code I've
>> instantiated and interfaced with to get some of the behaviour I am
>> seeking for the module.
>>
>> A clear API would make both testing/benchmarking simpler, as well as
>> module development.  The tight coupling and
>> functionality crossing multiple namespaces should also become clear as
>> the API progresses. A clear delineation between
>> the networking, scripting, and physics components would allow for better
>> independent testing and development of each
>> component.  Thoughts?
>>
>> While I've breached the subject of instrumenting and testing
>> Opensimulator, has anyone thought about a testing/QA
>> process on Opensim?
>>
>>
>
> --
> Justin Clark-Casey (justincc)
> OSVW Consulting
> http://justincc.org
> http://twitter.com/justincc
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20141209/5fbef3e6/attachment.html>