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

Tue Dec 9 22:07:30 UTC 2014

I agree that internals should not be frozen or forced to never change. I
disagree with the comparison to Linux. OpenSimulator is touted as "Provides
unlimited ability to customize virtual world applications through the use
of scene plugin modules <http://opensimulator.org/wiki/IRegionModule>.".
[1] Indeed, Region Modules can be viewed in this regard as somewhat
synonymous with Linux user-mode programs. However a clean delineation does
not exist between OpenSimulator core internals and Region Modules as exists
in Linux for user-mode programs. Indeed, such a interface may not be
possible with the current architecture. As such, externally developed
modules must rely upon in-core public object members to accomplish their
tasks. Since there is no way for those working on core to be aware of which
public methods are used in private modules it creates some difficulty when
trying to understand how such code could be used by externally developed
modules.

It may be unreasonable to demand a fully documented API plan before
implementing any sort of API. None of the rest of OpenSimulator has been
designed this way and has ever had to conform to such a constraint and I
see no benefit from forcing one now.

Again, I agree that we should not place unreasonable constraints on core
development. However I do not see why there cannot be a means to provide
deprecated core class member support for some period of time following a
change to internal public class members *when possible*. This can be viewed
as somewhat of a nuisance for core developers but given the abundance of
code development tools available, maintaining and deleting old deprecated
methods can be simplified with a bit of code searching. In this case some
courtesy is extended to developers of non-core modules which can help them
to plan around changes and proactively mitigate any unwanted effects.

[1] http://opensimulator.org/wiki/Main_Page retrieved 12/9/2014 1:30 pm PST

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/9d55a2bb/attachment.html>