One of the goals of the 0.6.0 release is to replace the current IClientAPI interface with something that will improve compatibility down the road with alternative clients. Instead of our current model where we dictate the features that clients must support, the new model will allow clients to pick and choose features we handle, and then implement them.
The basic way this is handled, is through the new ‘IClientCore’ interface. We introduced the IClientCore interface within a few hours of version 0.6.0 being tagged - however switching to the interface internally will take some time - probably a month or two, so any projects using IClientAPI are still safe.
As many of you who have played with writing region modules will know, IClientAPI represents everything you can do to every possible client - as one may guess, this doesnt scale when you begin adding multiple different clients into the mix. It also makes things difficult when two clients have the same feature in radically different ways.
As you can see in the diagram above - all the particulars of IClientAPI are bundled up together as one common interface. It is convenient - but it’s also problematic when it comes to implementing a new client, as you need to stub out every single function - and modules cannot tell whether a particular event or function was simply ignored by the client as unsupported.
Enter IClientCore
IClientCore is presently a very narrow interface - we’re defining it as everything a client must support, whether it likes it or not. As a consequence - we’re sticking to things that every single client has and implements in a common manner.
In practice - this means IClientCore dictates only the Name, ID and other very common internal parameters. It also needs to support two new ’special’ interfaces - Get<IFace>() and TryGet<IFace>(IFace out). These last two are the keys to how the new system works.
Under the new system - we implement interfaces for Chat, Primitives, and each seperate functionality group. It’s then possible to use, ‘IClientCore.TryGet<IClientChat>(…)’ which returns an interface to this clients IChat interface. If the client doesnt support chatting - then TryGet returns false.
The first most obvious question to arise here is related to how this looks more complicated than it used to be, and that’s definetely true - where we differ is that the new model means you need to check a client supports something before attempting to use it.
Previously we had no way from modules to indicate whether a feature was supported on clients - and we also had no way of handling extensions. This also means that if you choose to implement a new Client adapter for OpenSim, you dont need to implement the previous 350 functions and ignore any custom ones. You can write new interfaces for your custom features, and only implement interfaces from the Linden Viewer where you think you share enough functionality to make it useful.
In most cases - the changes arent fairly significant, you can see a comparison of two functions under the old and the new in the porting guide I wrote.
If anyone has any comments or questions relating to this, please let me know.