Talk:Plugin architecture

Glad to see a conversation blooming here. Any chance we can see a little consolidation of these pages, though? Looks like we're sprawling out quite a bit. -- Rob Linden 20:01, 12 February 2007 (PST)

semantics

This should probably be moved to Project:Plugin architecture
SignpostMarv Martin 13:17, 14 February 2007 (PST)

No, Project: is used for official metainformation about the open source project from linden lab. Things like policy statements and such. This namespace is fine. Gigs Taggart 13:30, 14 February 2007 (PST)

Is that LL policy, or a practice borrowed from the Wikipedia ?

SignpostMarv Martin 13:35, 14 February 2007 (PST)

Yes, it is LL's policy. The bug in Jira to use multiple namespaces was shot down and closed WONTFIX. Fragmenting the namespace has negative effects on searching and no real benefit. Namespaces should be used for pages that are fundamentally different in some way, not as a way to partition articles. Please don't use the Project: namespace for articles. Just create the article and then tag it with categories it fits in. People can bring up the category page to look through pages in that category. Gigs Taggart 13:45, 14 February 2007 (PST)

WEB-22 was Rob shooting down Strife's request to have "LSL" added as a custom namespace, not Rob shooting down any and all uses of built-in namespaces.

If this article is intended to be a hub for the standardisation and development of plugins & plugin architecture, then it should be moved to Project:Plugin architecture, as it would be a "project" within the SL Wiki, as opposed to an article which describes the plugin architecture once it's defined.

SignpostMarv Martin 14:35, 14 February 2007 (PST)

P.S. This wouldn't go under "This wiki should function as one wiki, rather than as a bunch of tiny wikis that happen to share the same domain name.", as it is purely for organisational purposes, whereas Strife seems to want to segregate the wiki.

SignpostMarv Martin 14:40, 14 February 2007 (PST)

Actually, "Project:" should be reserved for meta information about this wiki itself. On most MediaWiki installs, the "Project:" namespace is equal to the name of the wiki itself, but I unset that option, thus "Project:" is the sole way of getting to that namespace. The things that go into the "Project:" namespace should be limited to those things that are about editing policy, etc. -- Rob Linden 14:47, 14 February 2007 (PST)

Ah. So is Project:Internationalisation a good use of the namespace or not ?

SignpostMarv Martin 15:16, 14 February 2007 (PST)

Looks good to me. Gigs Taggart 15:56, 14 February 2007 (PST)

plugin creation complexity

1. How complex are plugins going to be to create ?
2. Could plugins be written in notepad, or would they have to be developed in an IDE then compiled ?
3. If a plain-text scripting language were to be used, what languages would be advocated for use ? Javascript (yay greasemonkey!) ? Perl ? Ruby ? Python ? All of the above ?

SignpostMarv Martin 19:34, 14 February 2007 (PST)

We're not even close to this point in development or planning. I'm pretty sure higher level scripting languages will make it into client plugins eventually.

--- Baba Yamamoto 19:10, 16 February 2007 (PST)

parameter passing

I don't like the idea of anonymous pointers for parameter passing. I think that some kind of parameter list is essential.

typedef struct {
  int sl_param_id;  // Defined in the particular function's API
  enum {
    SL_INT32, SL_INT64, SL_FLOAT32, SL_FLOAT64, SL_STRING, SL_ALLOCED_STRING, ...
  } sl_type;        // Plugin may ignore parameters 
  int sl_required;  // If set, plugin MUST handle this parameter
  int sl_changed;   // Zero before any plugin called, non-zero if any plugin has changed it
  int64_t sl_value; // If the type is only 32 bits long, high 32 bits must be zero.
} sl_param;
typedef enum { SL_OK, SL_INCOMPATIBLE, SL_ERROR, SL_BREAK } sl_result;

sl_result sl_plugin(int count, sl_param params[], sl_param *error_info);

The function calling the plugin can have all these set in a static structure, and only needs to zero out the sl_changed parameters and set up the initial values. Plugins do not call plugins, the list of plugins for the function are called sequentially by the sl_handle_plugins routine.

if(my_plugins != NULL) {
  my_params[0].sl_changed = 0;
  my_params[0].sl_value = whatever;
  final_result = sl_handle_plugins(my_plugins, 1, my_params, &error_param);
  if(final_result == SL_BREAK) return success;
  if(final_result == SL_ERROR) {
    panic(error_param);
    return failure;
  }
}

The plugin must at a minimum:

• verify that the sl_param_id values are what it expects and handle (even if by ignoring) the wrong values
• handle (even if by ignoring the parameter) the "wrong" types
• return SL_INCOMPATIBLE if any of the parameters it's ignoring have sl_required set.
• set sl_changed for any parameters it's changed
• fill in error_info if it returns SL_ERROR
• free an SL_ALLOCED_STRING if it changes the string
• make sure that the type of a string parameter is SL_ALLOCED_STRING or SL_STRING to let the caller or later plugins know how to deal with them

The plugin may:

• Handle changes to the order of parameters as indicated by sl_param_id
• Handle changes to the types of parameters as indicated by sl_type
• Behave differently if a previous plugin has changed a parameter

Return values:

• SL_OK - Normal return, go on to the next plugin
• SL_INCOMPATIBLE - This plugin no longer works with this call. Let the user know and don't call this plugin again.
• SL_ERROR - This plugin has detected an error sufficiently severe that this call must abort. Should be rare.
  • error_info must be set to { original_param_id, SL_STRING or SL_ALLOCED_STRING, TRUE, TRUE, error_message }.
• SL_BREAK - Don't call any further plugins, don't run the rest of the function, the plugin has completely handled the call.

-- Argent Stonecutter 06:48, 22 February 2007 (PST)

content from Implementing new features

Embedded scripting language for client-side plugins

Heather Goodliffe, Yumi Murakami, Argent Stonecutter

• Make the client more powerful and plugable
• Embed a scripting language, such as Javascript or Tcl or LUA or Python, within Second Life to enable client plug-ins to be written in a modular fashion. Client plugins would be distributed via Second Life itself; hopefully LL would eventually agree to create a new object type for these, but for testing purposes notecards would probably suffice.
• Let me second that: I'd like to see client-side scripting as well. It should be easy to add that (in particular, using Lua), and it would let users fix so many usability problems. At a minimum, the scripting language should be able to access the functionality available through the menus, it should permit key bindings and grab keys, access preference settings, and it should be able to listen to chat and IM, so that commands can be triggered from there. Jherek Cerminara

One way of doing this would be to exploit the xpcom architecture of Mozilla. Exposing the viewer core as xpcom interfaces. That way the flexibility and extensibility of the Mozilla engine could be used.

The viewer already includes the mozilla engine, using xpcom it will be possible to use Javascript, Java, C++ (Mono/.Net is under way).

This would require that a definition of an interface layer between the core viewer and the xpcom system inside Mozilla, once that was defined and implemented, the viewer functionality could be extened using almost any language.

Duffy Langdon 12:34, 10 January 2007

• Something to note: the above plugin architecture would make automatic glue code for scripting languages easy to write. Argent Stonecutter 06:56, 22 February 2007 (PST)