Still only read-only for notecards, huh?

no offworld would be the best for those situations, just for sanity and speed sake



yes simple storage of AV data is what is needed, a cupon box, sales tracker whatever its just not worth while in SL today, you either rely on random joes webserver or babysitting a script, with popular places mutiple times a day

along with any complicated storage system that gets ezly overwhelmed

plus think of the system resources ppl could save, how many of you are running dummy scripts left and right, with (upto) multidimensional communications just for the sake of usable ram

i know i am

now think of the stress relief on the vm



secondlife is a puzzle to me, they want all this cooperate participation, but yet you have to bend over backwards for the simplest things

In my 30 years, I have heard the reverse pretty often, too.

"Insider: That's actually a good idea! Thanks!"

Of course, you only hear it from Insiders with open minds and lack of insecurity about their programming talents, which is fairly rare.



Well, with SL, "what they were meant for" changes often as the users figure out a way to use the world beyond "what LL meant it be used for". Notecards CAN be general purpose files that applications read and write, but we know that the way they are implemented right this moment won't support it, though it *could* be modified to do so.



Those 40 years must have been theoretical programming experience. While I am a big supporter of OOP and object persistence, here is the practical view:

1) LSL is a "common paradigm" language, built on a "new paradigm" platform. Sort of. What I mean by that is that LSL lacks classes, objects, inheritance, polymorphism, etc, yet it has the basic means of object persistence. IE, the platform supports it, but there is no way to manage it. As such, to take advantage of the platform, the language would need to have these things as part of its core.

2) Why would it need to save anything externally? Beyond the point above, here are a couple more practical ones:
a) Available space - This is a biggie. To do anything remotely useful with data management, 16k is TINY. Worse yet, you can't really use all of the 16k as data; some code has to be in there to manipulate it, and pass-by-value halves the remaining available space, unless all you are doing is adds and queries. Yes, you CAN do it with multiple scripts, but it is slow, and the more scripts you use, the slower it (and the sim) gets.
b) Reliability - Ever had a sim crash and do a rollback on you? Lost data. Ever had your in-world server completely disappear? Lost data. Ever had your script just completely stop running on you for no reason? Lost data. You see, scripts really aren't as persistent as you might like to think. The design of SL provides no mechanism to ensure the necessary reliability and integrity required for most data management applications. In fact, script state is maintained as a courtesy (cum luxury) more than a utility.

Personally, I would MUCH prefer real objects and real object persistence, with an effort to provide real reliability. However, like everything else in SL, we make do with what we have and what we can weedle out of LL that doesn't go too far beyond their capabilities. If some way could be provided to us for writable notecards (or, hell, simple DBMS functionality), I'd take it.

The question in my mind then becomes, what would be easier? To add writable notecards, or refactor the entire LSL platform to incorporate real OOP and Object Persistence? They are already well underway with the Mono project, but from the sound of it, it will just be interpreting LSL initially, not embracing advanced features and/or extending LSL with them.



Been there, done that, got the T-shirt. It doesn't get around any of the issues described above, and is nowhere near as elegant and useful as writable notecard functionality, for the same kinds of applications and requirements.

>> b) Reliability - Ever had a sim crash and do a rollback on you? Lost data. Ever had your in-world server completely disappear? Lost data. Ever had your script just completely stop running on you for no reason? Lost data. You see, scripts really aren't as persistent as you might like to think.

yep. LOL. And yes, SL is just a game, but you tell some steaming woman that whose L$700 order you've just lost all trace of, grin.


here's a post from june 2006 showing how limited it is, sadly.
/54/d5/196041/1.html

Squirrel Wood
Registered User
... And with lists you need to keep in mind that if the list becomes too long (memory wise) the script will either generate an error or "start over" with an empty list all of a sudden.

A short memory management script can hold aboot 100 name/uuid values.

Actually, I was looking for this feature as well, when I started writing scripts in LSL. I'd rather have some file to store my data than save it into a variable and take the risk that the thing crashes and everything gets lost.
As for the stuff I own and just use myself, this isn't that much of a problem. I know where to put what into a notecard and then read it out there on rezzing the object. The problem starts, when you have some items that you sell and then tell the new owner (who usually has just little knowledge about the system) that he has to enter all the configurations into a notecard. Chances are, that the customer screws up and the system isn't running as it should. Customisable objects are a nightmare with such a system. Not to say that I don't want a customer to edit a card, but rather have him/her fill in a form with nice textfields, where I can check the input, check for malicious code and so on.
The only text-field, where a user can enter data is the chat... and there, the user has usually to add some channel on which he/she wants to talk to the object.
This is far from being customer-friendly.
So the ONLY solution is actually: set up a web-service and let the user edit the configuration off-world. But then - there's this RPC-Limitation that lets me only transfer a small amount of data to the object in-world. Means, I have to send the object a request, make the object requesting the data... WTH? It works - sort of... but it's far from being 'handy' as well...
When I found out that the RPC-Request existed, I was excited - up to the point, when I realised, that the amount of data is just small. I had to go back to HTTP, which also raises the amount of requests to the server and makes everything more complicated and slow.
Talking 'bout shops and business: as long as I can't store images on an external server and request them from in-world, this is all a bunch of crap (sorry). I can store data in a Database, but for the illustrations for that data, I have to upload images first? This sucks, really. I do have some nice business ideas, but to get them really working, I need the ability to load external pictures. NO customer would jump on that train if I told him/her to upload the images separately and then add them to an object.
So - storing data off-world is a good idea (and I actually prefer it, vs. storing stuff in a notecard). But to make this really valuable, I need better communication (means more push-data) and some other add-ons to communicate with a webserver than just what we have now...

Ok - this wasn't 2 cents - rather a buck or two...

This is what amuses me the most. All the "insiders" who tell us that there are workaround solutions and that implementing a basic storage system would use too many resources. How many resources are the workarounds using!! lmao

Read/write data storage can be done via llHTTPRequest(), get used to it, it's not gonna change any time soon in the future.

We are used to it, thanks for your input.

good question, course i dont have a sim stress meter but i can tell you having a flat file sitting in a database takes up alot less resources than 5 scripts sitting around sucking idol time to get the same amount of storage (storage + framework) 24-7-365

and of course scripts are volatile to boot, thats exactly what i want in my storage solution

it can be done with rpc, didnt stop them from installing html

next time please read the post before inputting your 2 cents on something we already covered

html is a pita for marketable SL products, html is great if I want to store data, but if someone else wants to i am all of a sudden in the web hosting biz

>> Johan Laurasia writes: Read/write data storage can be done via llHTTPRequest(), get used to it, it's not gonna change any time soon in the future.

>> Osgeld Barmy. html is a pita for marketable SL products, html is great if I want to store data, but if someone else wants to i am all of a sudden in the web hosting biz

exactly. If I were to get somebody using something dependent upon llHTTPRequest() to store data off-world, somebody all of a sudden is on the hook for not getting hit by a car to make sure that offworld web data storage place is still around. Mind you, Johan might suggest that we just merely store that at a super-reliable IBM data facility for the minor cost of $1500 US a month, but you'd have to flog a heck of a lot of T-shirts a month just to break even, LOL. If it's you doing it Johan and you're doing it for free, you're morally obliged to stay interested in SL for several years to keep that off-world website storage running, long after it's just a pita.

That being said Johan, I think we all agree with you: it's not gonna change any time soon in the future. What I've been saying is, IBM right now has "more than 5,000 employees who inhabit Second Life and other online universes." [1] . Don't you think maybe they're making notes of all the shortcomings, and in prep for what? If IBM's in the picture in the future, for sure there will be data. And besides, what is "anytime soon"? Remember the expression "internet time"?

____________________________

[1]. Konrad, Rachel. IBM guidelines govern virtual employees. Associated Press. 26 July 2007.

IBM Looks at New Virtual Transactions Methods

"IBM aims to invest the majority of its research and development dollar into building software that can link traditional transaction systems to modern interfaces, for example, releasing automatic teller machines that link to banks in virtual worlds such as Second Life," said SVP Steve Mills. Of course, IBM also has its eyes on its own platform, Multiverse, so Second Life is likely only one application. The Smart Bank Application simulates high-volume banking environments and links virtual ATMs to real-time authorization from a core banking system over the Web. The Computer Weekly [URL]article highlights three purchases that build into IBM's transaction strategy. The company announced plans to purchase Princeton Softech to give users cheaper storage and greater access to historical data; in July it bought Data Mirror, a package that allows real-time transfer and identification of data; and in June it bought Telelogic to help users develop industry-specific software.

From: Virtual Worlds Weekly - Volume 1, Issue 24 - August 13, 2007

Eek! some attachments are more vital than one's left foot even! (grin)

There is a potentially vast resource in SL that is effectively going to waste, in that each server box has a hard drive, shared by the 4 simulators on that box. As far as I know it is being used only to do server dumps on the hour for rollback purposes. If we had a set of new commands along the lines off:
Integer handle = llOpenFile(string filename)
Void llCloseFile(Integer handle)
Integer linenumber llWriteFile(Integer handle, string message)
string message llReadFile(Integer handle, Integer linenumber)
void llDeleteFile(Integer handle)

Obviously the file would not transfer with the object, but the object could create the file in an on_rez event and from then on and data accumulated should be reasonably resilient without putting any extra load on the Asset Servers.
Obviously the commands I suggest are just a guess, I have not really thought this trough, but as a topic for discussion, do you think it could be feasible?
A similar system could be implemented using the client’s local drive, but this has the obvious down side of requiring the client to be online in order for the script to access the file. I have done some experiments in the latter case by intercepting chat at the client level and using paste into chat to return data. It is messy but has potential in some applications and if browser plug-in support is implemented one day, I see this as the first plug-in I would want.
Obviously a common solution sanctioned by Linden Labs is preferable.

Having had another cup of coffee I just realized why my above suggestion is not feasible.
The Simulators are not tied to the hardware and on a restart could conceivably come back up on any server of the same hardware class. I suppose some kind of key pointing to the file could be utilized but the resultant network traffic and the key tracking would probably have a greater impact on the asset servers and grid than any current method.
Oh well, I will continue my experiments with local storage.

Just to go of on a tangent for the moment, so far the topic has been about technical details.

Has anyone considered the legal implications of this, I can only speak from the point of view of UK law but i assume other countries have similar legislation.

If as a business on SL, I take RL details of my customers this will fall within the data protection act and I must on request disclose all details held on my computer about a person. If LL allow persistant data storage then that information would be held on there systems and they would fall within the act. To then have to work out what details they have on any givven individual by trawling thourgh the entire asset server really is not an option.

It could be, but I don't think the data protection act works like that. If you want to know what data a company has on you, you have to approach that company. I don't think you can call up that company's database colocation firm and ask them for all the data they have on you for all the companies they host. I'm not a lawyer though!

what's with all the necro posting recently?

I'm not a lawyer either, the point im making is why should LL even get involved in that swamp, The big boys like IBM will host there own servers, but the ones without much knowledge would just keep there database with the lindens. So the lindens would be providing free storage and potentially putting themselelvs at risk of legal action.

Don't get me wrong, as a developer i would love to see perment storage, but i can see reasons why its not going to happen, and they are not all technical reasons.

Some subjects never die

increase of intelligence

I believe LL already do. Minor details such as our name, age, geographical location, credit card numbers.... :}

agreed, but that is there database over which they have control, not a random and ad hoc selection of info collected by users over which they have no control

Agreed, with that added refinement.

hmmm that would assume either someone would have revived this before the current thread on the same topic, or that OP would have revived this one instead....

People can already store vital data on notecards. They just can't do it by script. I doubt the legal consequences would change a great deal. It's not "what", but the, "how" and "how much", that would change.