[sldev] LSL initiated Prim metadata was Re: Plugin architecture

[Jason Giglio]

Argent Stonecutter wrote:
-snip bunch of irrelevant crap-

I think we need to go over how this works again, you are completely 
missing the point.  Please read carefully.

Suppose I want to implement the client side part web textures, so that 
Linden Lab can easily pick up the patches and make minor server side 
changes to support it and then it'll be done.

Right now, it's kinda hard to do that, because there's no way to 
associate this new metadata with a prim, without using something hacky 
like the description field, or having it OwnerSay the stuff over and 
over.  Either method means that it'll have to be rewritten later on when 
the actual protocol is updated to take advantage of the feature.  My 
proposal eliminates that rewriting.

This system allows me to implement web textures in a way that can be 
easily picked up by Linden Lab and transitioned into a real feature.

You notice this has *nothing* to do with plugins, not directly.

Here's how it would work.

1. I make up my mini API for web textures:
	webtext, face<facenumber>, <url>

2. Then, on my testing prims I insert the LSL Script:
	llSetMetaInformation("webtext, face1, 
http://www.m.com/webtexture.php?text=my%20text");
	//inserts string into tag 0 for this prim.

3. Then, in the client I begin to make my modifications, which read tag 
0 and use that data.  I ensure that it's easy to change which tag number 
that my feature is assigned to, for the day when it is accepted and 
moved to a real tag number.

4. I test the feature, and encourage other *developers* (including 
linden lab) to test it too, by applying my client side patches, and 
using the LSL to set tag 0 on some test prims to the strings that my 
feature is expecting.

5.  Feedback is gotten from Linden Lab developers on the feature, and 
the feature is patched/updated/further developed.

6. The feature is accepted by Linden Lab.  Linden Lab can then assign 
the feature a unique tag number, lets say 1001.

7. Linden Lab implements:

llSetWebTexture(string url, integer face);  //Updates prim tag 1001 with 
"webtext, face<facenum>, <url>"

Note that this uses my same API except it is now on a high tag that 
can't be modified directly by users.

The client is updated by changing a single constant, that tells the web 
texture feature to look for tag 1001 instead of tag 0.

8.  Done!

You'll notice that this is entirely a development tool.  It is not meant 
to be used by end users, ever.  There is no way for anyone except Linden 
Lab to modify any tag other than tag 0.  Tag 0 is solely for development 
testing purposes.

There is no chance for any "support for undocumented features" problem 
like you mention.