I agree that it isn't a great situation for module writers at the moment.
But speaking as someone who easily does the most work in core at this time and for much time before that, having internal public methods go through a deprecation cycle is not sustainable. There are a huge number of public methods because different projects in the OpenSim solution need to call each other or because inexperienced coders did not recognise the value of partitioning code complexity. And the overwhelming majority of changes are not renames but non-trivial restructurings to make OpenSimulator work better or make it possible to move forward without the weight of a huge amount of sometimes nonsensical organic cruft.
I do not believe that it is unreasonable to ask the people who want APIs to spend a bit of their own time working out what these should be. Not only because internal methods should be free to change but also because those internal methods are a very poor mechanism for manipulating the simulator from a module, not having been designed for that at all.
It would be quite possible to have a set of interface implementations available via Scene.RequestModuleInterface() and similar that sit on top of the internal code but present a consistent and less varying face to the region modules. The stuff in Opensim/Region/OptionalModules/Scripting/Minimodule is an example of this, though that didn't go through any significant review process to my knowledge. Not all API needs to be designed at once - it can easily be done piecemeal.
OpenSimulator has been changing internal code without anything significant in the way of deprecation since its inception. I see changing that as a new constraint upon existing behaviour.
On 09/12/14 22:07, Dahlia Trimble wrote:
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 <[email protected] <mailto:[email protected]>> 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 <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] <mailto:[email protected]> http://opensimulator.org/cgi-__bin/mailman/listinfo/opensim-__dev <http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev> _______________________________________________ Opensim-dev mailing list [email protected] http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
-- 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
