Talk:Plugin architecture

From Second Life Wiki
Revision as of 06:56, 18 February 2007 by SignpostMarv Martin (talk | contribs) (content from Implementing new features)
Jump to navigation Jump to search

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)

content from Implementing new features

Embedded scripting language for client-side plugins

Heather Goodliffe, Yumi Murakami

  • Make the client more powerful and plugable
  • Embed a scripting language, such as 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