• All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you have read, understood, and agreed to those terms.
Issue Details (XML | Word | Printable)

Key: SVC-1406
Type: New Feature New Feature
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Argent Stonecutter
Votes: 110
Watchers: 36
Operations

If you were logged in you would be able to see more operations.
2. Second Life Service - SVC

Non-volatile storage for meta-information

Created: 01/Feb/08 08:51 AM   Updated: 13/Aug/09 05:03 PM
Return to search
Component/s: Scripts
Affects Version/s: None
Fix Version/s: None

Issue Links:
Relates


 Description  « Hide
This is a formal request for the extended version of extensible prim attributes*, which I'm opening as "major" because the quote-fix-unquote for SVC-674 makes the issue of non-volatile script- and user- editable configuration associated with objects even more critical.

Proposed design, (originally from the Wiki):

The root prim (or any prim) of an object would have an associated list of name-value pairs. The name would be a string and the value could be a string, or alternatively it could be a simple type (string, key, integer, float, vector, or rotation). This list would be saved and restored with the prim, and a client could register its interest in specific values that would be delivered to it. This is similar to MUCK attributes, UNIX environment variables, file metadata in BeFS and later file systems, Lisp property lists, and so on. It's a powerful, efficient, and easily generalized mechanism.
LSL API

llCreateProp(string name, integer perm);
llSetPropString(string name, string value);
string llGetPropString(string name);
llSetPropStringKey(string name,key object,string value);
// key must be an object in the same sim, and the object must be owned by the script owner or have appropriate permissions
string llgetPropStringKey(string name,key object);
// key must be an object in the same sim, and the object must be owned by the script owner or have appropriate permissions

Permissions:
1 ANY_READ
2 ANY_WRITE
4 GROUP_READ
8 GROUP_WRITE
16 READ_PROTECT
32 WRITE_PROTECT

READ_PROTECT and WRITE_PROTECT mean that scripts outside the prim can not read or write the attribute.

This means that the default 0 permission should do the right thing in most cases.

The total amount of space available for all attributes on the root prim of an object would be limited to 1024 bytes. This 1024 bytes would include the name, the permission byte, and the value. It could be stored as the permission byte value, a nul-terminated UTF name, and the nul-terminated value, followed immediately by the next value. Two consecutive nulls (zero-length name) would terminate the list. This implementation worked well for early UNIX on machines whose CPU power and available memory was of the same magnitude as an LSL script.

*https://wiki.secondlife.com/wiki/Extensible_Prim_Attributes_from_LSL which includes a more sophisticated version of this that includes client-server communication for open-source client extensions.

 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Argent Stonecutter made changes - 01/Feb/08 08:52 AM
Field Original Value New Value
Link This issue is related to by SVC-674 [ SVC-674 ]
Argent Stonecutter made changes - 01/Feb/08 08:52 AM
Link This issue is related to by SVC-701 [ SVC-701 ]
Argent Stonecutter made changes - 01/Feb/08 08:55 AM
Link This issue is related to by MISC-907 [ MISC-907 ]
Argent Stonecutter made changes - 01/Feb/08 08:56 AM
Link This issue is related to by SVC-186 [ SVC-186 ]
Argent Stonecutter made changes - 01/Feb/08 08:56 AM
Link This issue is related to by SVC-1118 [ SVC-1118 ]
Argent Stonecutter made changes - 01/Feb/08 08:59 AM
Link This issue Relates to SVC-701 [ SVC-701 ]
[ Permlink | « Hide ]
Argent Stonecutter added a comment - 01/Feb/08 08:59 AM
Linked to SVC-701 (which could be implemented as a special case of this) and SVC-1115 (for a similar function for agents).

Argent Stonecutter made changes - 01/Feb/08 08:59 AM
Link This issue Relates to SVC-1115 [ SVC-1115 ]
Argent Stonecutter made changes - 01/Feb/08 09:00 AM
Link This issue is related to by SVC-1394 [ SVC-1394 ]
Argent Stonecutter made changes - 01/Feb/08 09:02 AM
Description This is a formal request for the extended version of extensible prim attributes*, which I'm opening a "major" because the quote-fix-unquote for SVC-674 makes the issue of non-volatile script- and user- editable configuration associated with objects even more critical.

Proposed design, from the Wiki:

The root prim of an object would have an associates list of name-value pairs. The name would be a string and the value could be a string, or alternatively it could be a simple type (string, key, integer, float, vector, or rotation). This list would be saved and restored with the prim, and a client could register its interest in specific values that would be delivered to it. This is similar to MUCK attributes, UNIX environment variables, file metadata in BeFS and later file systems, Lisp property lists, and so on. It's a powerfule, efficient, and easily generalised mechanism.
LSL API

llCreateProp(string name, integer perm);
llSetPropString(string name, string value);
string llGetPropString(string name);
llSetPropStringKey(string name,key object,string value);
// key must be an object in the same sim, and the object must be owned by the script owner or have appropriate permissions
string llgetPropStringKey(string name,key object);
// key must be an object in the same sim, and the object must be owned by the script owner or have appropriate permissions

Permissions:
1 ANY_READ
2 ANY_WRITE
4 GROUP_READ
8 GROUP_WRITE
16 READ_PROTECT
32 WRITE_PROTECT

READ_PROTECT and WRITE_PROTECT mean that scripts outside the prim can not read or write the attribute.

This means that the default 0 permission should DTRT in most cases.

The total amount of space available for all attributes on the root prim of an object would be limited to 1024 bytes. This 1024 bytes would include the name, the permission byte, and the value. It could be stored as the permission byte value, a nul-terminated UTF name, and the nul-terminated value, followed immediately by the next value. Two consecutive nulls (zero-length name) would terminate the list. This implementation worked well for early UNIX on machines whose CPU power and available memory was of the same magnitude as an LSL script.

*https://wiki.secondlife.com/wiki/Extensible_Prim_Attributes_from_LSL which includes a more sophisticated version of this that includes client-server communication for open-source client extensions. 		This is a formal request for the extended version of extensible prim attributes*, which I'm opening a "major" because the quote-fix-unquote for SVC-674 makes the issue of non-volatile script- and user- editable configuration associated with objects even more critical.

Proposed design, from the Wiki:

The root prim of an object would have an associated list of name-value pairs. The name would be a string and the value could be a string, or alternatively it could be a simple type (string, key, integer, float, vector, or rotation). This list would be saved and restored with the prim, and a client could register its interest in specific values that would be delivered to it. This is similar to MUCK attributes, UNIX environment variables, file metadata in BeFS and later file systems, Lisp property lists, and so on. It's a powerful, efficient, and easily generalized mechanism.
LSL API

llCreateProp(string name, integer perm);
llSetPropString(string name, string value);
string llGetPropString(string name);
llSetPropStringKey(string name,key object,string value);
// key must be an object in the same sim, and the object must be owned by the script owner or have appropriate permissions
string llgetPropStringKey(string name,key object);
// key must be an object in the same sim, and the object must be owned by the script owner or have appropriate permissions

Permissions:
1 ANY_READ
2 ANY_WRITE
4 GROUP_READ
8 GROUP_WRITE
16 READ_PROTECT
32 WRITE_PROTECT

READ_PROTECT and WRITE_PROTECT mean that scripts outside the prim can not read or write the attribute.

This means that the default 0 permission should do the right thing in most cases.

The total amount of space available for all attributes on the root prim of an object would be limited to 1024 bytes. This 1024 bytes would include the name, the permission byte, and the value. It could be stored as the permission byte value, a nul-terminated UTF name, and the nul-terminated value, followed immediately by the next value. Two consecutive nulls (zero-length name) would terminate the list. This implementation worked well for early UNIX on machines whose CPU power and available memory was of the same magnitude as an LSL script.

*https://wiki.secondlife.com/wiki/Extensible_Prim_Attributes_from_LSL which includes a more sophisticated version of this that includes client-server communication for open-source client extensions.
Argent Stonecutter made changes - 01/Feb/08 09:03 AM
Description This is a formal request for the extended version of extensible prim attributes*, which I'm opening a "major" because the quote-fix-unquote for SVC-674 makes the issue of non-volatile script- and user- editable configuration associated with objects even more critical.

Proposed design, from the Wiki:

The root prim of an object would have an associated list of name-value pairs. The name would be a string and the value could be a string, or alternatively it could be a simple type (string, key, integer, float, vector, or rotation). This list would be saved and restored with the prim, and a client could register its interest in specific values that would be delivered to it. This is similar to MUCK attributes, UNIX environment variables, file metadata in BeFS and later file systems, Lisp property lists, and so on. It's a powerful, efficient, and easily generalized mechanism.
LSL API

llCreateProp(string name, integer perm);
llSetPropString(string name, string value);
string llGetPropString(string name);
llSetPropStringKey(string name,key object,string value);
// key must be an object in the same sim, and the object must be owned by the script owner or have appropriate permissions
string llgetPropStringKey(string name,key object);
// key must be an object in the same sim, and the object must be owned by the script owner or have appropriate permissions

Permissions:
1 ANY_READ
2 ANY_WRITE
4 GROUP_READ
8 GROUP_WRITE
16 READ_PROTECT
32 WRITE_PROTECT

READ_PROTECT and WRITE_PROTECT mean that scripts outside the prim can not read or write the attribute.

This means that the default 0 permission should do the right thing in most cases.

The total amount of space available for all attributes on the root prim of an object would be limited to 1024 bytes. This 1024 bytes would include the name, the permission byte, and the value. It could be stored as the permission byte value, a nul-terminated UTF name, and the nul-terminated value, followed immediately by the next value. Two consecutive nulls (zero-length name) would terminate the list. This implementation worked well for early UNIX on machines whose CPU power and available memory was of the same magnitude as an LSL script.

*https://wiki.secondlife.com/wiki/Extensible_Prim_Attributes_from_LSL which includes a more sophisticated version of this that includes client-server communication for open-source client extensions. 		This is a formal request for the extended version of extensible prim attributes*, which I'm opening as "major" because the quote-fix-unquote for SVC-674 makes the issue of non-volatile script- and user- editable configuration associated with objects even more critical.

Proposed design, from the Wiki:

The root prim of an object would have an associated list of name-value pairs. The name would be a string and the value could be a string, or alternatively it could be a simple type (string, key, integer, float, vector, or rotation). This list would be saved and restored with the prim, and a client could register its interest in specific values that would be delivered to it. This is similar to MUCK attributes, UNIX environment variables, file metadata in BeFS and later file systems, Lisp property lists, and so on. It's a powerful, efficient, and easily generalized mechanism.
LSL API

llCreateProp(string name, integer perm);
llSetPropString(string name, string value);
string llGetPropString(string name);
llSetPropStringKey(string name,key object,string value);
// key must be an object in the same sim, and the object must be owned by the script owner or have appropriate permissions
string llgetPropStringKey(string name,key object);
// key must be an object in the same sim, and the object must be owned by the script owner or have appropriate permissions

Permissions:
1 ANY_READ
2 ANY_WRITE
4 GROUP_READ
8 GROUP_WRITE
16 READ_PROTECT
32 WRITE_PROTECT

READ_PROTECT and WRITE_PROTECT mean that scripts outside the prim can not read or write the attribute.

This means that the default 0 permission should do the right thing in most cases.

The total amount of space available for all attributes on the root prim of an object would be limited to 1024 bytes. This 1024 bytes would include the name, the permission byte, and the value. It could be stored as the permission byte value, a nul-terminated UTF name, and the nul-terminated value, followed immediately by the next value. Two consecutive nulls (zero-length name) would terminate the list. This implementation worked well for early UNIX on machines whose CPU power and available memory was of the same magnitude as an LSL script.

*https://wiki.secondlife.com/wiki/Extensible_Prim_Attributes_from_LSL which includes a more sophisticated version of this that includes client-server communication for open-source client extensions.
[ Permlink | « Hide ]
Jesse Barnett added a comment - 01/Feb/08 02:36 PM
voted!

[ Permlink | « Hide ]
Chaz Longstaff added a comment - 01/Feb/08 02:43 PM
SL has got to sh*t or get off the pot. If it is a development platform, we need something like this. If not, it's just a game, and we can all pack up and turn our TV's back on.

[ Permlink | « Hide ]
Dale Glass added a comment - 01/Feb/08 05:23 PM
I like the idea, though I'd like a bigger size limit. Perhaps 16K now that Mono is getting the memory limit bumped to 64K.

The reason is that I think that too tight limits are harmful. The 16K LSL limit means some scripts have to be artificially split, so the end result is that resources get wasted on duplicated code and link messages. The same way, I'd expect people to work around a 1K limit by creating multiple objects, communicating over chat.

I could live with the system as described, but I think it'd be better to have some spare room.


[ Permlink | « Hide ]
LaeMi Qian added a comment - 01/Feb/08 05:41 PM
I'd also like an extra tab in object properties that can (at the scripter's option per name:value pair - another perms flag per pair?) list names and values with the values in an appropriate-to-the-variable-type edit-field. IE. a place where a creator can set up user-editable preferences without the user having to open edit and save notecards.

[ Permlink | « Hide ]
Argent Stonecutter added a comment - 01/Feb/08 06:26 PM
I agree, there should be a user interface in the edit box for this, or even right off the pie menu for world-writable properties.

Permissions maybe should be something like "creator/owner/group/any" rather than just "owner/group/any", so it could be used for things like copyright notices?


[ Permlink | « Hide ]
Argent Stonecutter added a comment - 01/Feb/08 07:38 PM
The reason for the 1024 byte limit is that this previous comments on the SLDEV list indicated that the amount of space potentially available for this kind of purpose was fairly small. 1024 bytes is actually on the upper end of what may be available.

[ Permlink | « Hide ]
Alvargi Daniels added a comment - 02/Feb/08 09:35 AM
In general I support this idea one added feature request:

A set of behavior attributes that define if a value is cleared, preserved, incremented or decremented when a new instance of the object is created (a more universally robust idea could be a NEW_INSTANCE flag in the change event)


[ Permlink | « Hide ]
Kami Harbinger added a comment - 02/Feb/08 11:14 AM
I would find it far more useful to have a larger database available. 16K would be a tolerable bare minimum, but the ability to add more would massively increase the utility of SL.

With a more limited memory space, I'd simply have to build banks of objects, consuming even more resources and making development harder.


[ Permlink | « Hide ]
Han Sontse added a comment - 02/Feb/08 05:27 PM - edited
An important consideration for this kind of storage is that it has to be small. At this time it is my understanding that a Prim is a few K bytes of data that must be transfered between sims on border crossings, and TPs. Increasing the footprint of a prim significantly is going to make transfer of objects between sims worse.

While I like the general notion of a Key/Value storage system in a prim, I'd like to see it simplified. A simple container exactly like the Description Field. A simple string. If a script developer wants to use a more intelligent storage model they can map it onto the string. K.I.S.S.

The only additional operations I'd like to see for a meta-data string would be a password lock to prevent alteration by rouge scripts eg:

string llGetMetaData(string password);
void llSetMetaData(string meta_data, string password);
void llSetMetaDataPassword(string password); – setting the password erases the existing meta-data

The calls are prim local, and I'd prefer that there be no support in the object editor for viewing or editing the meta-data. Scripts can avoid losing the password by hardcoding it into a protected script, and sharing it as needed with other scripts. A 16 char password would be more than sufficient to avoid brute force attacks if the calls had a 1 or 2 second delay.

NOTE: this storage model DOES NOT attempt to address bulk storage needs... I envision this type of storage being used for object preferences, and other persistent values that are not going to change very often, such as root URLS and credentials.
The main issue for me is avoiding loss of mission critical properties should a script crash or reset unexpectedly.

I don't think that LL should facilitate bulk storage in-world. The current XML-RPC and HTTP methods are more than adequate to handle communication with off-world data stores.

HS


[ Permlink | « Hide ]
Argent Stonecutter added a comment - 02/Feb/08 07:16 PM
Yes, of course I agree that it needs to be small, but making it a key/value scheme from the start will make it smaller, because the alternative to having key/value pairs for each script is to have separate linked prims for each script to keep their private data in. That's a false economy.

Yes, this is not for bulk data, it's for configuration parameters. The kind of stuff that you put in the description field. The stuff you have the user put in the description or a notecard. Which is why the user needs to be able to edit it, the way they can a description or a notecard. Which is why it needs to have a user interface for data the user's allowed to see or modify, in the object editor or directly from the pie menu, because we don't have the ability to have a script open up a dialog and enter a name.

As for passworded access: plaintext passwords are a nightmare, we don't need them here... use the UUID of the script. That's what the "creator" lock is for. DON'T pass a password around between scripts, listeners can steal it... the gateway script would be the owner of that keyed value, and would pass the value itself around (or use it for whatever purpose).


Harleen Gretzky made changes - 05/Feb/08 06:33 AM
Link This issue is related to by SVC-1444 [ SVC-1444 ]
[ Permlink | « Hide ]
Innes McLeod added a comment - 15/Feb/08 06:23 PM
I agree that the permissions should include a creator permission. This would allow more flexibility for things such as the mentioned copyright notice, serial numbers, limited series of items (4 of 10 etc) and probably other things that we have not thought of. The values should copy with the prim if it is copied.

They would probably have to be prim based, not object based as the OP suggested, otherwise what would happen to a modifiable object that used this data, that was linked as a non-root prim, to another object?

A use I can see for this would be a nonvolatile serial number that could be set the first time an object is rezzed. Once the value is created it is could be write protected, making it read only. The value would stay with the object from then on.


[ Permlink | « Hide ]
Alvargi Daniels added a comment - 15/Feb/08 07:45 PM
This would be incredibly useful... the one issue I still see is how this non-volitile storage behaves on new instances of objects (objects with the copy attribute set).

One could record the UUID of the object into "creator" protected non-volitile storage and check that value aganst the UUID of current the instance and go from there. That soulution would work for objects that are rezzed, but would not for those copied in inventory.

For serialization use cases, inventory copies would need to be addressed.

This relates back to my earlier comment on inc, dec and clear behaviors.


Argent Stonecutter made changes - 08/Jun/08 11:46 AM
Link This issue Relates to SVC-2508 [ SVC-2508 ]
Sue Linden made changes - 13/Nov/08 12:04 PM
Workflow jira-2007-12-22a [ 51677 ] jira-2008-11-14 [ 80653 ]
Sue Linden made changes - 13/Nov/08 04:29 PM
Workflow jira-2008-11-14 [ 80653 ] jira-2008-11-14a [ 86702 ]
Sue Linden made changes - 13/Nov/08 04:45 PM
Workflow jira-2008-11-14 [ 86702 ] jira-2008-11-14a [ 91781 ]
Sue Linden made changes - 13/Nov/08 04:55 PM
Workflow jira-2008-11-14 [ 91781 ] jira-2008-11-14a [ 95280 ]
Fake Fitzgerald made changes - 11/Dec/08 10:55 PM
Link This issue is related to by SVC-3515 [ SVC-3515 ]
[ Permlink | « Hide ]
Elwe Ewing added a comment - 26/Dec/08 09:02 AM
Really good idea, but from Argent we're used to get them
I took the time to extend this request, adding the Alvaragi's comment, to SVC-3515 which should more easy-to-use from LSL (and this support is nearly fully implemented by "Objects comments" yet )

[ Permlink | « Hide ]
Argent Stonecutter added a comment - 26/Dec/08 01:48 PM
Why do you think a numerically indexed storage system would be easier to use than a string-indexed one?

Stephen Psaltery made changes - 28/Mar/09 11:43 AM
Link This issue is related to by SVC-4048 [ SVC-4048 ]
Argent Stonecutter made changes - 20/May/09 05:38 AM
Description This is a formal request for the extended version of extensible prim attributes*, which I'm opening as "major" because the quote-fix-unquote for SVC-674 makes the issue of non-volatile script- and user- editable configuration associated with objects even more critical.

Proposed design, from the Wiki:

The root prim of an object would have an associated list of name-value pairs. The name would be a string and the value could be a string, or alternatively it could be a simple type (string, key, integer, float, vector, or rotation). This list would be saved and restored with the prim, and a client could register its interest in specific values that would be delivered to it. This is similar to MUCK attributes, UNIX environment variables, file metadata in BeFS and later file systems, Lisp property lists, and so on. It's a powerful, efficient, and easily generalized mechanism.
LSL API

llCreateProp(string name, integer perm);
llSetPropString(string name, string value);
string llGetPropString(string name);
llSetPropStringKey(string name,key object,string value);
// key must be an object in the same sim, and the object must be owned by the script owner or have appropriate permissions
string llgetPropStringKey(string name,key object);
// key must be an object in the same sim, and the object must be owned by the script owner or have appropriate permissions

Permissions:
1 ANY_READ
2 ANY_WRITE
4 GROUP_READ
8 GROUP_WRITE
16 READ_PROTECT
32 WRITE_PROTECT

READ_PROTECT and WRITE_PROTECT mean that scripts outside the prim can not read or write the attribute.

This means that the default 0 permission should do the right thing in most cases.

The total amount of space available for all attributes on the root prim of an object would be limited to 1024 bytes. This 1024 bytes would include the name, the permission byte, and the value. It could be stored as the permission byte value, a nul-terminated UTF name, and the nul-terminated value, followed immediately by the next value. Two consecutive nulls (zero-length name) would terminate the list. This implementation worked well for early UNIX on machines whose CPU power and available memory was of the same magnitude as an LSL script.

*https://wiki.secondlife.com/wiki/Extensible_Prim_Attributes_from_LSL which includes a more sophisticated version of this that includes client-server communication for open-source client extensions. 		This is a formal request for the extended version of extensible prim attributes*, which I'm opening as "major" because the quote-fix-unquote for SVC-674 makes the issue of non-volatile script- and user- editable configuration associated with objects even more critical.

Proposed design, (originally from the Wiki):

The root prim (or any prim) of an object would have an associated list of name-value pairs. The name would be a string and the value could be a string, or alternatively it could be a simple type (string, key, integer, float, vector, or rotation). This list would be saved and restored with the prim, and a client could register its interest in specific values that would be delivered to it. This is similar to MUCK attributes, UNIX environment variables, file metadata in BeFS and later file systems, Lisp property lists, and so on. It's a powerful, efficient, and easily generalized mechanism.
LSL API

llCreateProp(string name, integer perm);
llSetPropString(string name, string value);
string llGetPropString(string name);
llSetPropStringKey(string name,key object,string value);
// key must be an object in the same sim, and the object must be owned by the script owner or have appropriate permissions
string llgetPropStringKey(string name,key object);
// key must be an object in the same sim, and the object must be owned by the script owner or have appropriate permissions

Permissions:
1 ANY_READ
2 ANY_WRITE
4 GROUP_READ
8 GROUP_WRITE
16 READ_PROTECT
32 WRITE_PROTECT

READ_PROTECT and WRITE_PROTECT mean that scripts outside the prim can not read or write the attribute.

This means that the default 0 permission should do the right thing in most cases.

The total amount of space available for all attributes on the root prim of an object would be limited to 1024 bytes. This 1024 bytes would include the name, the permission byte, and the value. It could be stored as the permission byte value, a nul-terminated UTF name, and the nul-terminated value, followed immediately by the next value. Two consecutive nulls (zero-length name) would terminate the list. This implementation worked well for early UNIX on machines whose CPU power and available memory was of the same magnitude as an LSL script.

*https://wiki.secondlife.com/wiki/Extensible_Prim_Attributes_from_LSL which includes a more sophisticated version of this that includes client-server communication for open-source client extensions.
[ Permlink | « Hide ]
Stephen Psaltery added a comment - 20/May/09 08:09 AM
Argent, I think you have a wonderful implementation. I'm wondering though if the lindens will want to go to all that trouble. Might it not be wiser to campaign for the nonvolatile storage of a string and let us manage it?

[ Permlink | « Hide ]
Argent Stonecutter added a comment - 21/May/09 05:36 AM - edited
A single string manually managed would add very little functionality to what we already have. You can already store more manually managed meta-information in a storage script: what this provides is a common shared framework that all scripts can use.

And it's not that much work to get the basic functionality. All I'm asking for is the environment vector from Version 7 UNIX in 1978.


Dzonatas Sol made changes - 13/Jun/09 08:26 PM
Link This issue Relates to SVC-98 [ SVC-98 ]
Sebastean Steamweaver made changes - 11/Aug/09 12:08 PM
Link This issue is related to by MISC-3077 [ MISC-3077 ]
Sebastean Steamweaver made changes - 13/Aug/09 05:03 PM
Link This issue is related to by MISC-3077 [ MISC-3077 ]

Powered by Atlassian JIRA the Professional Issue Tracker. (Enterprise Edition, Version: 3.13.2-#335) - Bug/feature request - Atlassian news - Contact Administrators