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
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
