Talk:Plugin architecture

This is a talk page associated with the Open Source Portal. Changes to all pages like this one can be tracked by watching the "Related Changes" for "Category:Open Source Talk Page"
Please sign comments you leave here by putting four tildes (~~~~) at the end of your comment. For more guidelines, see Talk Page Guidelines

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 the new 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)

Automated Agents

Just curious, how does "Automated Agents" become a plugin ?

Or are you referring to "headless agents" in the context of having all IMs for a Resident's alts routed through into one instance of SL ?

SignpostMarv Martin 22:15, 23 February 2007 (PST)

Security Concerns

I believe the hardest part of the plug-in system will be to overcome to security concerns. How many trust being able to download and plug-in arbitrary code that might set off a money event. I've heard the casual user of SL not want to deal with such concerns. For that reason, I believe a scripting language is the way to go. We can limit the availability of the API to the scripts. This can be the default to allow arbitrary code in the form of scripts. Dzonatas Sol 01:54, 7 April 2007 (PDT)

Unless a plugin disables the big-ass blue box notice that says "You just have Resident X L$10k", I think that it'll be difficult to wholesale rip people off.

The suggested method for getting around the security concerns thing would be to have something like https://plugins.secondlife.com whereby each plugin listed on the site has been given the all-clear by Linden Lab as "not ripping people off".

The API cannot be limited, as it'll be just a case of modifying the source code.

SignpostMarv Martin 04:56, 7 April 2007 (PDT)

I'm pretty sure that a review system as you suggested above won't scale. Dzonatas Sol 11:29, 8 April 2007 (PDT)

Of course it won't. It's more reliable than limiting the API though.

SignpostMarv Martin 02:53, 9 April 2007 (PDT)

It would be easier to allow an option to limit access to the API by default. Let the user decide to over-ride that. Also, there could be certification key like web browser do now. It wasn't the intent to make it impossible for even certifiable plug-ins to gain greater access. Dzonatas Sol 13:49, 9 April 2007 (PDT)

L$ handling should go through the same permissions system an LSL-initiated call goes through.

'Plugin Foo created by Bar requests permission to debit your account'

A web-based interface along the lines of flickr should be a usable means of managing permissions.

SignpostMarv Martin 16:45, 9 April 2007 (PDT)

Some of this discussion happened a couple months back during Rob's office hours. Really, if the plugins are dynamically loadable libraries, you can't do much for security. Even if you don't expose something in the API, it's still accessible so long as the plugin has access to the memory space. What would make a lot of sense is creating scripting engines as plugins. If a scripting system proves to be secure, we might be able to eventually convince Linden Lab to ship the scripting system themselves.

Creating a scripting system plugin should be pretty straightforward once the plugin system exists, so long as the scripting language has a nearly a one-to-one mapping of script functions to plugin API functions. --Soft Noel 13:23, 10 April 2007 (PDT)

All the same security issues apply to any third-party clients anyway. So why consider solutions that wouldn't be feasible in a discussion of the security of the whole executable? --Prodigal Maeterlinck 13:59, 29 November 2007 (PST)

Not everyone uses third-party clients. Many people avoid them for security reasons. Argent Stonecutter 14:35, 31 December 2007 (PST)

Scripting API for security

Some scripting languages have "Safe" interpreter modes: Javascript and Tcl immediately come to mind. Also, scripts are more easily eyeball-firewalled. Argent Stonecutter 14:35, 31 December 2007 (PST)

External plugins for security

While an external plugin, connected through a socket of some kind, could still use code injection attacks on the viewer it does raise the bar a little. On the other hand external plugins are limited in what they can do in the viewer... you would need to have them communicate (by chat, say) to a HUD to provide a user interface in-game. Still, this would be a useful option for many applications. Argent Stonecutter 14:35, 31 December 2007 (PST)