|
|
|
[
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).
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.
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. 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.
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? 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.
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) 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. 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); 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. 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 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). 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. 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. 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 ) Why do you think a numerically indexed storage system would be easier to use than a string-indexed one?
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?
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. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Non-volatile storage for meta-information
