Talk:Plugin System/API


 * Hehehe, using the current approach of ennumeration, this page will become thousands of lines long. ;-)
 * I suggest that we start off with a catchall requirement: Subject to coding up an appropriate access method for each case, a plugin should be able to query every readable datum in the viewer, should be able to set every writeable datum in the viewer, and should be able to trigger every in-viewer and in-world action that the human operator can trigger.
 * Using that catchall requirement as a base, we can then shrink our list to just those items that illustrate expected functionality or expand on interesting cases, or items that suggest new functionality that should be added to the viewer in support of more ambitious plugin API requirements. Morgaine 11:41, 18 December 2008 (UTC)
 * I took the Be Bold prime directive to heart, and added an initial Base Requirement section, as per above. Morgaine 11:58, 18 December 2008 (UTC)


 * Collecting lots of list items is the idea. ;-) First create a list of things that people are actually interested in a plugin being able to do, then shape that into an API. While "a plugin should be able to read and write everything" is a nice ideal, it provides very little guidance about which things are (most) worth implementing. Jacek Antonelli 12:58, 18 December 2008 (UTC)
 * My finger hovered over the undo button for a while when I saw that you deleted the Base Requirement because that sort of undermines the base capability of the mechanism, but I've decided not to revert but to go along with your point that "collecting lots of list items is the idea". :-) However, I am going to add a line to the effect that these requirements do not represent any kind of full set, but are only representative of what our plugin system can achieve since it is far more general than any enumeration of examples can convey. Morgaine 03:08, 6 January 2009 (UTC)
 * Perhaps we should move most of the page contents to an "API Wishlist" page, with an explanation that they are just a few guides/examples/reminders of some things we want to make sure the API can eventually do, but is not comprehensive, exclusive, or set in stone? I'm not opposed to the long-term goal of an API that can do practically everything, but I do think we need a list of specific desirable features, just so we have something to focus on. Jacek Antonelli 17:05, 6 January 2009 (UTC)
 * Update: I've done so now. See the Plugin System/API Wishlist page. Jacek Antonelli 01:34, 8 January 2009 (UTC)

What about implementing existing Plugin APIs first? :)
This is probably just a silly suggestion, but what about integrating the Restrained Life API first? Oh, I know, this only appeals right now to the BDSM groups; however, interesting tools like the ever-popular Mystitools, if they detect a Restrained Life-enabled SL viewer (like the Cool Viewer...), will add extra functionality, like the ability to mute IMs from people you don't wish to listen to (allowing you not to be busy).

I know that your ultimate purpose is to have native plugins, and this is really just a hack, not a real Plugin API. Still, it's immensely popular, and has contributed to a widespread use of the Cool Viewer — because so many people use the Mystitools :) It would be nice to make Imprudence compatible with it too.

(yes, I'm breaking the rules of the way comments are added here :) but that's why there is the nice "+" sign ;)

Gwyneth Llewelyn 17:01, 14 February 2009 (UTC)