Second Life Wiki - User contributions [en]

SLDev Resident Names

2007-11-01T05:13:03Z

Bushing Spatula: (don't ask...)

[[SLDev]] > '''SLDev Resident Names'''

Most things associated with Second Life development (in-world meetings, wiki editing, JIRA) are done using Second Life names, but posting on the mailing list is often done using another name (real name or non-Second Life alias). This page is intended as a decoder ring for people to figure out who's who on the [[SLDev]] mailing list.

Don't reveal any information you don't want to, but if you post messages to the SLDev mailing list under a different name than your Second Life Resident name, please consider dropping your name in the table. (Tip: putting three tildes, e.g. "<nowiki>~~~</nowiki>", will automatically convert to your name and a link to your username on this wiki) :

{|border="1" cellpadding="2" class=sortable
|-
!| SLDev Posting Name
!| Second Life Resident Name
|-
| Andre Roche || [[User:Ryozu Kojima|Ryozu Kojima]]
|-
| Andy Estes || [[User:Drewan Keats|Drewan Keats]]
|-
| Callum Lerwick || [[User:Seg Baphomet|Seg Baphomet]]
|-
| Dirk Moerenhout || [[User:Blakar Ogre|Blakar Ogre]]
|-
| Dzonatas || [[User:Dzonatas Sol|Dzonatas Sol]]
|-
| Ettore Pasquini || [[User:Abstra Apparatchik|Abstra Apparatchik]]
|-
| Harold "LabRat" Brown || [[User:Thraxis Epsilon|Thraxis Epsilon]]
|-
| Jason Giglio || [[User:Gigs Taggart|Gigs Taggart]]
|-
| John Hurliman || [[User:Eddy Stryker|Eddy Stryker]]
|-
| Laurent Laborde || [[User:Kerunix Flan|Kerunix Flan]]
|-
| Lawson English || [[User:Saijanai Kuhn|Saijanai Kuhn]]
|-
| Matt Kimmel || [[User:Feep Larsson|Feep Larsson]]
|-
| Mike Monkowski || [[User:Mm Alder|Mm Alder]]
|-
| Nik Radford || [[User:Nik Woodget|Nik Woodget]]
|-
| Neovo Geesink || [[User:Neovo Geesink|Neovo Geesink]]
|-
| Paul Nolan || [[User:Paul Churchill|Paul Churchill]]
|-
| Rob Lanphier || [[User:Rob Linden|Rob Linden]]
|-
| Ben B yer || [[User:Bushing Spatula|Bushing Spatula]]
|-
| Dana Fagerstrom || [[User:Whoops Babii|Whoops Babii]]
|-
| Dirk Husemann || [[User:Dr Scofield|Dr Scofield]]
|-
| Mark Burhop|| [[User:Burhop Piccard|Burhop Piccard]]
|}

Region feature requirements

2007-09-20T05:14:24Z

Bushing Spatula: initial creation

(Off the top of my head) Here are some features which individual sims may or may not support. We should decide on which features a compliant sim MUST support, and which it MAY support.

* Physics
* Portals
* Building
* Crossings (from other arbitrary sims)
* Estate management
* Money (Lindens, private currency?)
* Chat
* Voice
* Instant Messaging, Intra-Sim
* Instant Messaging, Inter-Sim
* Various avatar attributes, such as prim attachments
* Scripting (LSL, mono?, etc)

Please add your own ideas, and feel free to rearrange this list.

Workitems for Meeting 1

2007-09-17T07:23:05Z

Bushing Spatula: started splitting out subpages

* WORKITEM: use case librarian (started [[Use Cases|here]])
* WORKITEM: list possible additional/replacement domains
* WORKITEM: explore alternative models of decomposition
* WORKITEM: use cases which expose need for alternative decomposition
* WORKITEM: design for extension
* WORKITEM: design for [[Discovering Capabilities]]
* WORKITEM: how to provide [[streaming input]]
* WORKITEM: [[URL addressing]] requirements
* WORKITEM: identify functions by at least by Linden Lab's use (at least), and cluster as stateful and stateless
* WORKITEM: list the requirements that the community needs of identity to have the policies it wants
* WORKITEM: write the [[architectural design]] principles
* WORKITEM: we need to list a set of agent rights (e.g. being able to leave a region)
* WORKITEM: what are the feature sets that regions may or may not implement ([[Region feature requirements]])
* WORKITEM: a list of possible parameters to consider (e.g. region size: should they be something other than 256x256m)
* WORKITEM: figure out [[vhosting possibilities]] for regions
* WORKITEM: if there are good use cases for topology changes to the architecture, capture
* WORKITEM: classify [[modes of content use]] (not exhaustive list of every possible use)
* WORKITEM: we need a clear definition of what parts of an object are included vs which parts are referential
* WORKITEM: need to define [[avatar rights on privacy]]
* WORKITEM: Rob, Zero, Liana will get chat and irc logs posted to sldev; blog post; slides up on wiki... This will take a few days to complete
* WORKITEM: come back in two weeks with everyone deciding what they can commit to
* WORKITEM: Mark: post list of messages in the wiki

[[Category:Architecture Working Group]]

SLDev Resident Names

2007-09-08T17:03:41Z

Bushing Spatula: added meself

[[SLDev]] > '''SLDev Resident Names'''

Most things associated with Second Life development (in-world meetings, wiki editing, JIRA) are done using Second Life names, but posting on the mailing list is often done using another name (real name or non-Second Life alias). This page is intended as a decoder ring for people to figure out who's who on the [[SLDev]] mailing list.

Don't reveal any information you don't want to, but if you post messages to the SLDev mailing list under a different name than your Second Life Resident name, please consider dropping your name in the table. (Tip: putting three tildes, e.g. "<nowiki>~~~</nowiki>", will automatically convert to your name and a link to your username on this wiki) :

{|border="1" cellpadding="2" class=sortable
|-
!| SLDev Posting Name
!| Second Life Resident Name
|-
| Andre Roche || [[User:Ryozu Kojima|Ryozu Kojima]]
|-
| Andy Estes || [[User:Drewan Keats|Drewan Keats]]
|-
| Callum Lerwick || [[User:Seg Baphomet|Seg Baphomet]]
|-
| Dirk Moerenhout || [[User:Blakar Ogre|Blakar Ogre]]
|-
| Dzonatas || [[User:Dzonatas Sol|Dzonatas Sol]]
|-
| Ettore Pasquini || [[User:Abstra Apparatchik|Abstra Apparatchik]]
|-
| Harold "LabRat" Brown || [[User:Thraxis Epsilon|Thraxis Epsilon]]
|-
| Jason Giglio || [[User:Gigs Taggart|Gigs Taggart]]
|-
| Laurent Laborde || [[User:Kerunix Flan|Kerunix Flan]]
|-
| Lawson English || [[User:Saijanai Kuhn|Saijanai Kuhn]]
|-
| Matt Kimmel || [[User:Feep Larsson|Feep Larsson]]
|-
| Mike Monkowski || [[User:Mm Alder|Mm Alder]]
|-
| Nik Radford || [[User:Nik Woodget|Nik Woodget]]
|-
| Paul Nolan || [[User:Paul Churchill|Paul Churchill]]
|-
| Rob Lanphier || [[User:Rob Linden|Rob Linden]]
|-
| Ben Byer || [[User:Bushing Spatula|Bushing Spatula]]
|}

Version control repository

2007-05-21T05:38:58Z

Bushing Spatula: added OpenGrok link

{{CompileNav}}

Linden Lab runs an official Subversion repository that contains occasional snapshots from the internal Linden Lab source repository.

== Using the repository ==

* Create a location on your hard drive to check out the code (e.g. Linden Lab developers generally use $HOME/linden)
* Select which branch you'd like to check out (see [[Source branches]] for explanation of branches)
** release: <nowiki>http://svn.secondlife.com/svn/linden/release</nowiki>
** release-candidate: <nowiki>http://svn.secondlife.com/svn/linden/branches/release-candidate</nowiki>
** maintenance: <nowiki>http://svn.secondlife.com/svn/linden/branches/maintenance</nowiki>
** Branch_1-15-0: <nowiki>http://svn.secondlife.com/svn/linden/branches/Branch_1-15-0</nowiki>
** Branch_1-15-1: <nowiki>http://svn.secondlife.com/svn/linden/branches/Branch_1-15-0</nowiki>
** sculpties2: <nowiki>http://svn.secondlife.com/svn/linden/branches/2007/sculpties2</nowiki>

== Browse source ==

* [http://svn.secondlife.com/trac/linden/browser Browse source (using Trac)]
* [http://svn.secondlife.com/trac/linden Other tools]
* [http://www.openmetaverse.org:8180/source/ Search] and [http://www.openmetaverse.org:8180/source/xref/linden/ browse] source using [http://www.opensolaris.org/os/project/opengrok/ OpenGrok], hosted by OpenMetaverse

== Write access ==

Developers that have signed and submitted [http://secondlife.com/developers/opensource/submitting a contribution agreement] are eligible (not guaranteed) write access to the repository. Other considerations, such as patches submitted and reasons access is requested will also come into play.

== Unofficial repositories ==

Below are repositories maintained by individuals outside Linden Lab. These repositories are not affiliated with Linden Lab in any way.

=== OpenMetaverse ===

[http://openmetaverse.org OpenMetaverse] hosts an OpenSL project with a public subversion repository.

=== Cafuego ===

[http://au.ubuntu.cafuego.net/dists/edgy-cafuego/secondlife Cafuego's Edgy Stuff v1.0]

Linux Alpha and Firstlook clients, packaged for Linux Ubuntu Edgy on i386.

Crash logs

2007-04-25T11:15:12Z

Bushing Spatula: added some info links

Crash logs are a very important tool for debugging program crashes; they allow a developer to try to fix a bug that they have never personally witnessed. Second Life automatically submits crash logs to Linden Lab when the viewer crashes, but external developers can't see them. If you'd like the broader community to help find the bug that caused Second Life to crash on your computer, you should submit this info as an attachment to the appropriate [[JIRA]] bug.

The exact data you need to send varies on the platform:

* Mac: Please attach two files to the JIRA report
** the crash log, which will usually be called "Second Life.crash.log", and will be located in ~/Library/Logs/CrashReporter. If you'd prefer, you can search Spotlight for "CrashReporter"; it will be one of the Folder matches. (For a technical discussion of the contents of this file, refer to http://developer.apple.com/technotes/tn2004/tn2123.html)
** a System Profiler report, which contains all of the necessary data about your computer and the hardware inside of it, so that we may group problems with similar hardware together. From the Apple menu, go to About This Mac, then click on More Info. This will open the System Profiler utility; select File -> Save as, pick a name for the file, save it, and then attach it to your JIRA report. (See also http://developer.apple.com/bugreporter/bugbestpractices.html#SP)

* Windows:

* Linux

Crash logs

2007-04-25T11:10:05Z

Bushing Spatula: created page about crash logs

Crash logs are a very important tool for debugging program crashes; they allow a developer to try to fix a bug that they have never personally witnessed. Second Life automatically submits crash logs to Linden Lab when the viewer crashes, but external developers can't see them. If you'd like the broader community to help find the bug that caused Second Life to crash on your computer, you should submit this info as an attachment to the appropriate [[JIRA]] bug.

The exact data you need to send varies on the platform:

* Mac: Please attach two files to the JIRA report
** the crash log, which will usually be called "Second Life.crash.log", and will be located in ~/Library/Logs/CrashReporter. If you'd prefer, you can search Spotlight for "CrashReporter"; it will be one of the Folder matches.
** a System Profiler report, which contains all of the necessary data about your computer and the hardware inside of it, so that we may group problems with similar hardware together. From the Apple menu, go to About This Mac, then click on More Info. This will open the System Profiler utility; select File -> Save as, pick a name for the file, save it, and then attach it to your JIRA report.

* Windows:

* Linux

Hooking sending IMs

2007-02-13T04:23:36Z

Bushing Spatula:

void LLFloaterIMPanel::sendMsg()
{
LLWString text = mInputEditor->getWText();
LLWString::trim(text);
if (!gAgent.isGodlike()
&& (mDialog == IM_NOTHING_SPECIAL)
&& mOtherParticipantUUID.isNull())
{
llinfos << "Cannot send IM to everyone unless you're a god." << llendl;
return;
}
if(text.length() > 0)
{
// Truncate and convert to UTF8 for transport
std::string utf8_text = wstring_to_utf8str(text);
utf8_text = utf8str_truncate(utf8_text, MAX_MSG_BUF_SIZE - 1);
std::string name;
gAgent.buildFullname(name);

PLUGIN_HOOK("LLFloaterIMPanel::sendMsg", &utf8_text, &mOtherParticipantUUID);

const LLRelationship* info = NULL;
info = LLAvatarTracker::instance().getBuddyInfo(mOtherParticipantUUID);
U8 offline = (!info || info->isOnline()) ? IM_ONLINE : IM_OFFLINE;

[...]

bool otr_impanel_hook(void *data1, void *data2) {
fprintf(stderr, "otr_impanel_hook(%p, %p)\n", data1, data2);
std::string *str=(std::string *)data1;
// send OTR whitespace data tag
str->append(OTRL_MESSAGE_TAG_BASE);
str->append(OTRL_MESSAGE_TAG_V2);

LLUUID *uuid=(LLUUID *) data2;
char uuidbuf[40];
uuid->toString(uuidbuf);
fprintf(stderr, " %s to %s", str->c_str(), uuidbuf);
floater_printf("Sent OTR whitespace tag to %s\n", uuidbuf);
return TRUE;
}

Plugin architecture Low-level Architecture

2007-02-13T04:21:42Z

Bushing Spatula: /* Calls from viewer to plugin (hooks) */

The three technical challenges for creating a plugin architecture are as follows:

== Code loading ==
Dynamic loading of natively-compiled executable code can be accomplished with dlopen / dlsym in Linux and MacOSX and LoadLibrary on Win32.

[[dlopen code example]]

== Calls from viewer to plugin (hooks) ==

In order to override or enhance existing functionality in the viewer, we need to be able to replace some code with our own. One way to do this would be to install "hooks" into commonly-used functions. In the example implementation code below, you can hook any function by adding 'PLUGIN_HOOK("function_name", data1, data2)' to the top of the function.

When that macro is called, it looks to see if any hooks have been registered with a name that matches "function_name". If so, it executes each one in turn.

Each hook function can affect program execution in one of three ways:

* Pass event through -- a function might decide to ignore this hook based on the contents of data1 and data2, or it might do something which doesn't disrupt the program flow (such as adding data to an internal list for later use, or displaying a dialog box). In this case, it should just return TRUE.
* Modify params, pass event through -- as above, except the hook function can modify the contents of data1 and/or data2 before returning TRUE
* Swallow event: Sometimes, we want to completely override the function being hooked, for various reasons -- in this case, the plugin should return FALSE.

PLUGIN_HOOK executes each function in turn; if it function returns FALSE, it just issues a 'return' in the context of the hooked function. If all hooks return TRUE, control will eventually be passed to the hooked function.

[[hook example code]]

[[hooking sending IMs]]

== Calls from plugin to viewer (exposing an API) ==

Most plugins will want to call into the client and have it do things like display dialog boxes, send IMs, etc. Unfortunately, there's no simple way to do this.

Ideally, most interesting functions in the viewer would be broken out into dylibs / dlls so that plugins could link against them. This probably isn't practical.

The alternate solution is to pick a number of useful functions, build a function pointer table, and allow plugins to ask for them by name.

[[function pointer example code]]

Function pointer example code

2007-02-13T03:33:30Z

Bushing Spatula:

class viewer_func {
public:
const char * name;
func_ptr ptr;
viewer_func() {}
viewer_func(const char * n, func_ptr p) { name=n; ptr=p;}
};

class plugin_interface {
private:
hook * get_hook_by_name(const char *name);
viewer_func * get_viewer_func_by_name(const char *name);
public:
LLDynamicArray<hook> hooks;
LLDynamicArray<viewer_func> viewer_funcs;

void add_hook(const char *name, const func_ptr ptr);

void add_viewer_func(const char *name, func_ptr ptr);
char ** get_viewer_func_list();
char ** get_hook_list();

const char * get_interface_version();
void * call_viewer_func(const char *name, void *data1, void *data2);
bool call_hooks(const char *name, void *data1, void *data2);
void init();
//plugin_interface();
}

void plugin_interface::add_viewer_func(const char *name, func_ptr ptr) {
/* This should be called upon instantiation several times, once for
each internal viewer function we wish to expose to the plugins */
viewer_funcs.put(*(new viewer_func(name, ptr)));
}

viewer_func * plugin_interface::get_viewer_func_by_name(const char *name) {
// this should really be a hash table lookup
for(int i=0; i < viewer_funcs.count() ; i++)
if (!strcasecmp(name, viewer_funcs[i].name))
return &viewer_funcs[i];
return NULL;
}

void * plugin_interface::call_viewer_func(const char *name, void *data1, void *data2) {
viewer_func * func = get_viewer_func_by_name(name);
fprintf(stderr, "Calling '%s' @ %p\n", name, func);
if (func) return (void *)(func->ptr)(data1, data2);
else return NULL;
}

Function pointer example code

2007-02-13T03:33:09Z

Bushing Spatula:

Hook example code

2007-02-13T03:29:04Z

Bushing Spatula:

#include "lldarray.h"
// data1 and data2 may be used for any arbitrary user data.
// from_plugin should be set to FALSE if the function is being called due to a user's action,
// and TRUE if it is being called from another plugin. (The idea is to avoid event loops, but
// maybe there is a better way.
// If function pointer returns FALSE, and this is one of a series of callbacks for a hook,
// the function should terminate without passing control to any further plugins or to the
// rest of the viewer function. (This is to allow hook functions to "swallow" events by return FALSE.)
typedef bool (*func_ptr)(void *data1, void *data2);

class hook {
public:
const char * name;
LLDynamicArray<func_ptr> *hook_ptrs;
hook() {}
hook(const char *n) {name = n; hook_ptrs = new (LLDynamicArray<func_ptr>)();}
};

class viewer_func {
public:
const char * name;
func_ptr ptr;
viewer_func() {}
viewer_func(const char * n, func_ptr p) { name=n; ptr=p;}
};

class plugin_interface {
private:
hook * get_hook_by_name(const char *name);
viewer_func * get_viewer_func_by_name(const char *name);
public:
LLDynamicArray<hook> hooks;
LLDynamicArray<viewer_func> viewer_funcs;

void add_hook(const char *name, const func_ptr ptr);

void add_viewer_func(const char *name, func_ptr ptr);
char ** get_viewer_func_list();
char ** get_hook_list();

const char * get_interface_version();
void * call_viewer_func(const char *name, void *data1, void *data2);
bool call_hooks(const char *name, void *data1, void *data2);
void init();
//plugin_interface();

};

#define PLUGIN_HOOK(name, data1, data2) fprintf(stderr, "PLUGIN_HOOK(%s)\n", name); if(!gPluginInterface.call_hooks(name, (void *)(data1), (void *)(data2))) return;

extern plugin_interface gPluginInterface;

void plugin_interface::add_hook(const char *name, const func_ptr ptr) {
/* This function adds a named hook definition with nothing to call to the list.
It should be called once for each hooked function upon instantiation of
the plugin interface; the hook_ptrs lists will be filled in, if necessary,
by plugin init functions. We need a list of hook names (function names)
so that plugins can ask the interface what hooks it will export. */
fprintf(stderr, "add_hook(%s = %p)\n", name, ptr);
if(ptr) {
hook * myhook = get_hook_by_name(name);
if (myhook == NULL) {
fprintf(stderr, "ERROR: tried to add function to unknown hook %s\n", name);
return;
}
myhook->hook_ptrs->put(ptr);
} else
hooks.put(*(new hook(name)));
}

hook * plugin_interface::get_hook_by_name(const char *name) {
// this should really be a hash table lookup
for(int i=0; i < hooks.count() ; i++)
if (!strcasecmp(name, hooks[i].name))
return &hooks[i];
return NULL;
}

bool plugin_interface::call_hooks(const char *name, void *data1, void *data2) {
hook * func = get_hook_by_name(name);
if (func) {
for (int i=0; i < func->hook_ptrs->count(); i++) {
LLDynamicArray<func_ptr> *fptr_array=func->hook_ptrs;
func_ptr fptr=(*fptr_array)[i];
if (!(fptr)(data1, data2)) return FALSE;
}
return TRUE;
} else return FALSE;
}

Hook example code

2007-02-13T03:24:19Z

Bushing Spatula:

Dlopen code example

2007-02-13T03:22:05Z

Bushing Spatula:

void loadPlugins( const char *path ) {
#ifndef LL_WINDOWS
int (*slp_plugin_init)(plugin_interface *);

DIR * plugindir;
struct dirent * mydirent;
void * dlhandle;
char plugin_name[FILENAME_MAX];

plugindir = opendir( path );
if( NULL == plugindir ) {
llwarns << "Could not open plugins directory: " << path << llendl;
return;
}

while (mydirent = readdir(plugindir)) {
if(!strcasestr(mydirent->d_name, PLUGINEXT)) {
fprintf(stderr, "Ignoring non-plugin directory entry %s\n", mydirent->d_name);
continue;
}

snprintf(plugin_name, sizeof(plugin_name), "%s%s%s", path, gDirUtilp->getDirDelimiter().c_str(), mydirent->d_name);
fprintf(stderr, "Trying to load plugin: %s\n", plugin_name);
dlhandle = dlopen(plugin_name, RTLD_LAZY);
if (dlhandle==NULL) {
fprintf(stderr,"Error opening %s: %s\n", plugin_name, dlerror());
continue;
}

slp_plugin_init = (int(*)(plugin_interface*))dlsym(dlhandle, "initOSLPlugin");
if (!slp_plugin_init) {
fprintf(stderr,"Error looking up initOSLPlugin: %s\n", dlerror());
dlclose(dlhandle);
continue;
}
slp_plugin_init(&gPluginInterface);
//char * (*getName)(void) = (char *(*)())dlsym(*(itPlugins), "getPluginName" );
//vPlugins[ getName()
vPlugins->push_back( dlhandle );
}
#endif
}

Dlopen code example

2007-02-13T03:18:48Z

Bushing Spatula:

Plugin architecture Low-level Architecture

2007-02-13T03:11:49Z

Bushing Spatula:

The three technical challenges for creating a plugin architecture are as follows:

== Code loading ==
Dynamic loading of natively-compiled executable code can be accomplished with dlopen / dlsym in Linux and MacOSX and LoadLibrary on Win32.

[[dlopen code example]]

== Calls from viewer to plugin (hooks) ==

In order to override or enhance existing functionality in the viewer, we need to be able to replace some code with our own. One way to do this would be to install "hooks" into commonly-used functions. In the example implementation code below, you can hook any function by adding 'PLUGIN_HOOK("function_name", data1, data2)' to the top of the function.

When that macro is called, it looks to see if any hooks have been registered with a name that matches "function_name". If so, it executes each one in turn.

Each hook function can affect program execution in one of three ways:

* Pass event through -- a function might decide to ignore this hook based on the contents of data1 and data2, or it might do something which doesn't disrupt the program flow (such as adding data to an internal list for later use, or displaying a dialog box). In this case, it should just return TRUE.
* Modify params, pass event through -- as above, except the hook function can modify the contents of data1 and/or data2 before returning TRUE
* Swallow event: Sometimes, we want to completely override the function being hooked, for various reasons -- in this case, the plugin should return FALSE.

PLUGIN_HOOK executes each function in turn; if it function returns FALSE, it just issues a 'return' in the context of the hooked function. If all hooks return TRUE, control will eventually be passed to the hooked function.

[[hook example code]]
== Calls from plugin to viewer (exposing an API) ==

Most plugins will want to call into the client and have it do things like display dialog boxes, send IMs, etc. Unfortunately, there's no simple way to do this.

Ideally, most interesting functions in the viewer would be broken out into dylibs / dlls so that plugins could link against them. This probably isn't practical.

The alternate solution is to pick a number of useful functions, build a function pointer table, and allow plugins to ask for them by name.

[[function pointer example code]]

Plugin architecture Low-level Architecture

2007-02-13T03:07:39Z

Bushing Spatula:

The three technical challenges for creating a plugin architecture are as follows:

== Code loading ==
Dynamic loading of natively-compiled executable code can be accomplished with dlopen / dlsym in Linux and MacOSX and LoadLibrary on Win32.

[[dlopen code example]]

== Calls from viewer to plugin (hooks) ==

In order to override or enhance existing functionality in the viewer, we need to be able to replace some code with our own. One way to do this would be to install "hooks" into commonly-used functions. In the example implementation code below, you can hook any function by adding 'PLUGIN_HOOK("function_name", data1, data2)' to the top of the function.

When that macro is called, it looks to see if any hooks have been registered with a name that matches "function_name". If so, it executes each one in turn.

Each hook function can affect program execution in one of three ways:

* Pass event through -- a function might decide to ignore this hook based on the contents of data1 and data2, or it might do something which doesn't disrupt the program flow (such as adding data to an internal list for later use, or displaying a dialog box). In this case, it should just return TRUE.
* Modify params, pass event through -- as above, except the hook function can modify the contents of data1 and/or data2 before returning TRUE
* Swallow event: Sometimes, we want to completely override the function being hooked, for various reasons -- in this case, the plugin should return FALSE.

PLUGIN_HOOK executes each function in turn; if it function returns FALSE, it just issues a 'return' in the context of the hooked function. If all hooks return TRUE, control will eventually be passed to the hooked function.

== Calls from plugin to viewer (exposing an API) ==

Plugin architecture Low-level Architecture

2007-02-13T02:57:30Z

Bushing Spatula: /* Code loading */

Plugin architecture Low-level Architecture

2007-02-13T02:55:21Z

Bushing Spatula:

The three technical challenges for creating a plugin architecture are as follows:

== Code loading ==
== Calls from viewer to plugin (hooks) ==
== Calls from plugin to viewer (exposing an API) ==

Plugin architecture

2007-02-13T02:48:30Z

Bushing Spatula: /* Table Of Contents */

As of this writing (February 12, 2007), there's not an official plugin architecture in the Second Life viewer. However, there's been a lot of interest in developing one. This page (and the pages it links to) are an attempt to capture a lot of the informal discussion that has occurred so far.

== Table Of Contents ==

# Discussions
## [[Plugin_architecture_survey|Survey of Client Plugins as Potential Models]]
## [[Plugin_architecture_Security|Security Model Issues]]
## [[Plugin_architecture_Low-level Architecture|Low-level architecture]]
## [[Plugin_architecture_Cross_Platform|Cross Platform Issues]]
## [[Plugin_architecture_Stability|PlugIns affecting Client Stability]]
## [[Plugin_LSL_Communication|Plugin <--> LSL Communication Channels]]
# Required Changes

== Required Changes ==
Some changes in the code will be required to support plugins.

* Complete GUI and other classes with functions that would be expected to exist, but don't because nothing needed them yet. For instance, add method overloads that should logically exist.
* Allow multiple callbacks per message, as well as unregistering a previously registered one. Currently only one callback can be registered per message type.
* Verify that all the callbacks work in such a way that they wouldn't be confused by plugins. When a callback for a reply to a request runs it must make sure that the data to arrived is what was requested, and if not, ignore it.
* Add internal callbacks for events such as rendering a frame, receiving a chat message, etc.

[[Category:Feature Requests]]

Plugin architecture

2007-02-13T02:46:51Z

Bushing Spatula: /* Table Of Contents */

As of this writing (February 12, 2007), there's not an official plugin architecture in the Second Life viewer. However, there's been a lot of interest in developing one. This page (and the pages it links to) are an attempt to capture a lot of the informal discussion that has occurred so far.

== Table Of Contents ==

# Discussions
## [[Plugin_architecture_survey|Survey of Client Plugins as Potential Models]]
## [[Plugin_architecture_Security|Security Model Issues]]
## [[Plugin_architecture_Dynamic_Loading|Dynamic Loading Of Plugins]]
## [[Plugin_architecture_Hooks|Communications between plugins and viewer (hooks)]]
## [[Plugin_architecture_Cross_Platform|Cross Platform Issues]]
## [[Plugin_architecture_Stability|PlugIns affecting Client Stability]]
## [[Plugin_LSL_Communication|Plugin <--> LSL Communication Channels]]
# Required Changes

== Required Changes ==
Some changes in the code will be required to support plugins.

* Complete GUI and other classes with functions that would be expected to exist, but don't because nothing needed them yet. For instance, add method overloads that should logically exist.
* Allow multiple callbacks per message, as well as unregistering a previously registered one. Currently only one callback can be registered per message type.
* Verify that all the callbacks work in such a way that they wouldn't be confused by plugins. When a callback for a reply to a request runs it must make sure that the data to arrived is what was requested, and if not, ignore it.
* Add internal callbacks for events such as rendering a frame, receiving a chat message, etc.

[[Category:Feature Requests]]

Plugin architecture Dynamic Loading

2007-02-13T02:46:07Z

Bushing Spatula:

This can be accomplished using dlopen / dlsym on MacOS and Linux platforms; I understand that LoadLibrary can be used for a similar function under Win32.

Plugin architecture

2007-02-13T02:42:01Z

Bushing Spatula: /* Table Of Contents */

As of this writing (February 12, 2007), there's not an official plugin architecture in the Second Life viewer. However, there's been a lot of interest in developing one. This page (and the pages it links to) are an attempt to capture a lot of the informal discussion that has occurred so far.

== Table Of Contents ==

# Discussions
## [[Plugin_architecture_survey|Survey of Client Plugins as Potential Models]]
## [[Plugin_architecture_Security|Security Model Issues]]
## [[Plugin_architecture_Dynamic_Loading|Dynamic Updating and Loading Of Plugins]]
## [[Plugin_architecture_Cross_Platform|Cross Platform Issues]]
## [[Plugin_architecture_Stability|PlugIns affecting Client Stability]]
## [[Plugin_LSL_Communication|Plugin <--> LSL Communication Channels]]
# Required Changes

== Required Changes ==
Some changes in the code will be required to support plugins.

* Complete GUI and other classes with functions that would be expected to exist, but don't because nothing needed them yet. For instance, add method overloads that should logically exist.
* Allow multiple callbacks per message, as well as unregistering a previously registered one. Currently only one callback can be registered per message type.
* Verify that all the callbacks work in such a way that they wouldn't be confused by plugins. When a callback for a reply to a request runs it must make sure that the data to arrived is what was requested, and if not, ignore it.
* Add internal callbacks for events such as rendering a frame, receiving a chat message, etc.

[[Category:Feature Requests]]

Talk:Version control repository

2007-02-05T10:14:41Z

Bushing Spatula: bushing speaks!

== SVN ==

I'm happy with a read only SVN.

We are all developers. We can set up our own local SVN if we want a sandbox. [[User:Gigs Taggart|Gigs Taggart]] 15:13, 9 January 2007 (PST)

Agreed.
I think our repo should have a struture like....
* /trunk/slviewer/ Root of what we are given. You basically just need to check this one directory out to build the client.
* /tags/slviewer/slviewer-*/ tag of each revision that's distroed by LL as a set, perhaps with it's binaries, and the build outputs. (map files and .asm files anyone?)
* /branches/slviewer/slviewer-*.1/ Branches to deal with bugs that happen once a tag has been made. Any changes fixed on a branch should also be applied to the trunk too.
[[User:Kunnis Basiat|Kunnis Basiat]] 18:38, 9 January 2007 (PST)

* [[User:Adam Zaius|Adam Zaius]] 06:38, 8 January 2007 (PST) votes for SVN
** Directory structure something like:
*** /trunk -- Only editable by Linden Lab
*** /branches/users/<username>/ -- unlimited permissions by owner/creator for third-party source

Do we want to integrate the VCS with the Second Life authentication? Pluggability of authentication scheme seems like an important axis to consider. --[[User:Which Linden|Which Linden]] 09:27, 8 January 2007 (PST)

Giving users branches in SVN without a degree of trust is dangerous - purging history in SVN is intentionally very difficult, so a single (malicious) user could conceivably use up all the space in the server or host not-so-legal content (even if you svn rm something, it's still in the history). However if the trunk is pure svn, normal users can use things like svk if they want their own branches. --[[User:Ginko Bayliss|Ginko Bayliss]] 13:33, 9 January 2007 (PST)

: Very good idea to consider (VCS w/ SLA). I would highly recommend sourceforge due to its known ability to handle major traffic; however, we would not have the SLA. Despite that, there are many professional and mature tools that work directly with SVN, for example Subclipse.
: I suggest a tier level repository with modes for production, test, and development, and each with their own trunk, branches, and tags. Production is not distributed and is mainly read-only except for the few who update it. Production is updated with, and only from, approved patches from test. Test tier is updated by an approved group of individuals with patches from development tier. Test is not distributed but is not read-only like the production tier. Test is where people go to get latest working patches. It is similar to Debian's mid-tier. Development can be distributed (people can host their own local sandbox), and it is write-enabled by a larger group responsible to merge code. Once code has been basically approved as working in development, it moves to test, so several patches to development may result in only one patch to test, and that would be the same from test to production. [[User:Dzonatas Sol|Dzonatas Sol]] 10:04, 10 January 2007 (PST)

[[User:Eddy Stryker|Eddy Stryker]] 13:22, 9 January 2007 (PST) votes against SVN
* Branching/merging capabilities are hacked in, so instead of doing push or pull commands you are looking up revision numbers to figure out when you last backported and where the new merge should start
* No distributed version control like bitkeeper, git, mercurial, etc without using SVK which is a less than ideal solution
* Not designed for very large codebases like Second Life, where branching becomes unbearable
** To continue on this point, we had to repair the opensecondlife.org svn database over a dozen times while checking in the thousands of files that make up the full codebase. It's centralized atomic nature seems to start falling apart when you have very big commits or similar operations going on and multiple other people are trying to check out
* SVN is a centralized repository system, it's designed to allow a group of people work together on the same codebase. LL would either have to create two million svn accounts, or have someone take account requests and process them, including setting up permissions for each sandbox... it would become a nightmare very quickly. That's why large distributed projects like the Linux kernel used distributed version control. They use Git which is Linux only right now, but Mercurial is proving to be a very good competitor to Git with support for all major operating systems

[[User:Kunnis Basiat|Kunnis Basiat]] 22:35, 14 January 2007 (PST)
* While I agree with the fact that branching and merging is a bit wierd in SVN, it was designed that way from the start, it was designed to get around several of the design flaws that were present in CVS, though I agree it's not as intunitive as it should be, it allows for really good tracking, but it's also a bit confusing. LL has been using SVN for a while, so they should be familiar with how version control in SVN works.
* I Find SVN to be really stable.I've never had a problem with SVN, and I've used it for a couple years professionally, and I've been helping my latest company migrate to SVN. The only annoyance I have about SVN is it's lack of an "obliterate" command, which there is a workaround for, and the schedule of an addition of the command. Other then that issue, SVN has been in use for several years, it's a well tested tool, and if any issues arise while using it, it's likley that you can find support for it. I've only had to break out svnadmin once (to deal with the lack of obliterate, and I found a step-by-step on how to do it.)
* SVN is used by KDE. It has both binary and source files, which reflects what we would be checking into OpenSL, and I think that KDE would have more users editing it, and I'm pretty sure it has a larger codebase.
* I don't know what problem you had with your repo. I am using the windows version of SVN, and I took my existing repo that I've used for other projects and checked in all of the slviewer and libs in one big checkin, with no problems. It copied all ~9000 files and 160megs in about 5 mins.
* I agree that LL creating account for every developer is very unreasonable. I think LL should host a repo that only has "gold" code on it, ready for production, with tags for each build. There should not be a sandbox for every developer. I think that we should submit patches to LL that are diffs from the head version of the repo, then a LL employee can apply the patch, then check&verify it works and passes all tests, then finally commit the patch to the repo. What would the process for a LL employee to recieve a change, validate it, and apply it to production be with Mercurial? I don't know enough about it to say what it's like.
* I Agree the lack of a Distributed Version Control sucks, you've got me curious, I want to play with SVK now.

[[User:Bushing Spatula|Bushing Spatula]] 02:14, 5 February 2007 (PST) votes against SVN, with further comments below
* I use SVN professionally. We have a SVN repo with hundreds of thousands of lines of code (it's something like 2.9GB including history), and roughtly a dozen developers. It works pretty well with the following use model:
** Each dev has his own set of code -- we almost never step on each others' toes because the code is well-partitioned into subprojects
** All patches are initially saved as a branch -- one per bug -- which is then peer-reviewed. Once it passes review, the patch is merged into trunk.
While this may or may not be similar to how LL does things in-house with SVN, I think this is very different then allowing outside contributions from many people, many of whom will step on each others toes, and many of whom will submit patches that will not be accepted. See discussion below about distributed systems.
== Distributed version control ==

One reason I really like the distributed version control systems is because it really reduces the need for Linden Lab to be in the business of giving people their own sandboxes. Many of the newer systems are very easy to host, and merging from multiple repositories is much easier. -- [[User:Rob Linden|Rob Linden]] 07:25, 8 January 2007 (PST)

I agree. Please, if you're interested in this debate, go read up on the pros and cons of distributed version control before proceeding -- it's a complicated, nuanced issue.
My crude summary:
* DVC systems allow everyone to set up their own private, spiffy repository. There's no need for LL to make every developer an account, because
* It's really easy to make changes on your local repo, and really easy to integrate changes from upstream (IE new LL source drops), so you make sure your changes are still relevant and still valid with every release
* Once you're happy with your code, it's easy to make patches that you can pass around, post on mailing lists, etc -- and other people can seamlessly drop them into their own local repository without breaking other stuff
* Once everyone loves a patch, it's very easy to send that patch to LL in a form that is very easy for them to apply to their tree.

I'd tend to go with Mercurial, because it seems to have the greatest support and mindshare of the DVC systems right now, but I'd be happy with any of them. [[User:Bushing Spatula|Bushing Spatula]] 02:14, 5 February 2007 (PST)
=== Mercurial ===
Mercurial's claim: Mercurial is a fast, lightweight Source Control Management system designed for efficient handling of very large distributed projects.
----

[[User:Baba Yamamoto|Baba Yamamoto]] votes for this.
*No central repository.
*Easier branching and merging.

=== Darcs ===

Darcs is something you may want to investigate. I've used it for other projects, and it was simple and effective enough that the less technical folks have actually started using it for their own projects, it is so simple and effective. A possible con would be that it IS written in Haskell.. but that's not that problematic. --[[User:Ky Aska|Ky Aska]] 15:59, 8 January 2007 (PST)

We tried using darcs for a while in-house, and really <em>wanted</em> it to work, but it would frequently never finish operations on windows because it would consume too much memory. [[User:Phoenix Linden|Phoenix Linden]] 09:25, 9 January 2007 (PST)

Out of curiosity, how long ago was darcs tried? It might've gotten better since then - though I've heard that performance during conflict resolution is still rather bad. --[[User:Ginko Bayliss|Ginko Bayliss]] 16:32, 9 January 2007 (PST)

[[User:Don Linden|Don]] and [[User:Kelly Linden|Kelly]] Linden experimented with darcs between 2006.02 and 2006.03. The version was 1.0.2 on linux. The Win and Mac versions may have been different. The conclusion was that darcs could not yet handle large repositories. -- [[User:Andrew Linden|Andrew Linden]] 2006.01.10 09:21 (PST)

=== Bazaar ===
Bazaar seems to be the hot VCS of choice now days, might be worth considering. Not sure if the development model is applicable to SL or not. It's got quite a lot of buzz recently in the Linux/Ubuntu/Launchpad world, also seems to have Windows support. http://bazaar-vcs.org/

Might also be worth looking at using launchpad itself which includes the Bazaar VCS, bug tracking and other stuff, The back end is closed currently but Canonical might be quite happy to allow Linden labs to have a copy of it to host, Mark Shuttleworth recently post about SL http://www.markshuttleworth.com/archives/72 although it would probably be quite a lot of work to setup and the features like bug tracking might be duplicated with existing systems used by Linden (although it seems like it would be fairly easy to integrate them. --[[User:Hegemon Skall|Hegemon Skall]] 13:32, 26 January 2007 (PST)

=== Comparisons ===
Thought these might be useful, basically a list of features supported by each VCS:

http://bazaar-vcs.org/RcsComparisons
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
--[[User:Hegemon Skall|Hegemon Skall]] 17:38, 27 January 2007 (PST)