So far, barring any LL concepts, we have (as far as I know so far!) two designs of plugin system: 1: Socket-based plugins - as suggested by Morgaine. 2: D-Bus or similar existing IPC tool. 3: C++ Dynamically Shared Objects - my suggestion.
Morgaine's design has a couple advantages that I can think of: Namely, a distinct lawyer-approved separation of code allowing the plugins to be released under different licenses, and a fairly stable target to design around, meaning the socket API wouldn't typically change a lot across releases, plugins also could be built into other external packages that interface with the socket API to provide massive amounts of integration. However, it's disadvantages come along: Networking code in every plugin just to connect to the client, separate processes that have to be launched by something - presumably the client code, but not always... I'm not too sure about the D-Bus design, there hasn't been much discussion, other than it seems a lot like Morgaine's suggestion to me, just an available existent re-usable tool. That can be a good thing, as we wouldn't have to worry about the protocol, it would be already done. The last option is one I've seen references to across the 'net. All that would be written in the client software is one or more Interface Objects (those familiar with polymorphic design are very familiar with these,) and then a list or two of these for different tasks. For instance, one list could be for those that have registered themselves as Dynamic Script interpreters. These Interfaces would then be implemented by all plugins, depending on what tasks the plugin was spec'd to handle. Plugins would then be located in the plugins directory in the main install, and/or in a plugins directory under each profile. They would be loaded automatically upon startup of the client, and their functions would be called upon event. The event could be as simple as the last step in the render/update loops, or as detailed as when the user clicks or touches a keyboard button. They also are given access to various commands they can call in the client. The more the merrier. The advantages are that these marry right up to the client giving full-speed access, along with the ability to get into the nitty-gritty of the client's underpinnings. Also an easier way to code for a lot of programmers (like myself) who, while having a passing familiarity with networking code, are not terribly interested in writing plugins as clients to the client.... Disadvantages are a potential lock-in to the client's license, although I'm not sure about that, and the API could be easily changed while patching some other part of the client code. Each has it's pro's and con's. And my listing of such is by no means comprehensive! I want to see this hashed out and the best over-all design get implemented: Client capabilities would soar fast, and be done in a very modular way improving SL massively. Ricky Cron Stardust
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
