Still only read-only for notecards, huh?

So there has not been a way to figure out how to make a script have write access to a notecard huh?

This would come in very handy.

Nobody's "figured out" a way because such a way doesn't exist. The thinking probably goes that if it were possible to automatically generate new assets through script, the asset servers could/would be overwhelmed, whether deliberately (griefing) or not (poor scripting practices).

By thinking laterally you could at a pinch have the script send an email to you of what you want in the notecard and then you upload or send it to the scripted object as a new item?

Or a modified client

Not if updating a file was allowed.

yea this issue sums up a lindens mentality

You have to remember, if you ask for an update this huge, you're going to lose the asset servers for 2 weeks, the search, and your RL left foot. Well maybe not your foot. Probably your attachments though

Actually, I think there's a good reason why when you edit a notecard it becomes a new asset - namely, that it enables them to save storage in another way: by making any read-only notecards you give out all refer to the same asset on the server.

lost it for how many days last week? (evil grin)




not really imo, lets say your writing a notecard, i use ms word, but that doesnt translate special charaters like ' " , ~ ! ect, but as we all know the internet can disconnect, or loose packets, SL's servers can die at any time, Venus can align with pluto whatever, so i save the notecard

1 asset

then i go back and start re-editing the annoying ? marks back to their proper charaters, incermentally becuase ive got to whip up some dinner in a bit, then take a shower, maby come back to it tomarow because its getting late

2 assets
3 assets
4 assets
5 assets

hmm i really dont like the way that sentance is stated

6 assets

whoops spell check replaced "their" with "there"

7 assets

on second thought i think i should include that landmark

8 assets

and some pictures

9 assets

rearrange a cupple of things, im finally happy with the notecard

10 assets


now ive just created 10 notecard assets, but theres NO POSSIBLE WAY to view the previous 9, so why save them in the server? how is that efficient in any possible way?

Im suprised that my simple little question has turned into a thread like this... hmph

I believe there are garbage collections run from time to time.

But the reason is, I think, that you package your notecard with your spiffy new product and your spiffy new product sells 200 copies.. but for the notecard regeneration, that would mean 200 new identical notecards on the asset server.

In fact, the notecards don't even have to be read-only, because once they're changed they become new ones, so it doesn't matter if the original unchanged one is a copy of the same one everyone else has.

All of the issues discussed above have been solved already in other technologies, see Single Instance Storage. SIS persists until an object changes, that object then becomes a unique entity in the database. eg. If you are giving a notecard with your product and you sell a thousand of those products, there is only 1 notecard in the database until someone changes their copy of the notecard and then there are 2, 1 that is changed and 1 that is not ( and shared with 999 users).

Sure there are pros and cons, and of course some analysis would need to be done to really understand the impact of a SIS solution on the SL servers.

Anyway, putting all that aside for a moment, the advatange of being able to write to a notecard is so great that I would accept nearly any limitations to be able to do so. Sleep for 2 seconds after update, 5 updates per 100 seconds, only 1 updatable notecard per object etc You name it, I'd live with it.

This is exactly how SL already works. Choose a notecard in your inventory, copy its UUID and paste it into notepad. Drag a copy of the notecard into a prim, deed the prim to a group, then drag the card back to your inventory. Copy that card's UUID and paste into notepad on the next line. Same UUID.

This is why a new UUID is generated every time a notecard is altered and saved. The previous edit still exists, presumably until some periodic garbage collection finds that it is no longer in any agent or object's inventory, and wipes it.

To test this, I created a new notecard, entered "This is a test." into it, and saved it, then copied it's UUID. I edited the card to say "This is another test." and saved it again. Then I wrote a simple script that would, when touched, pass the UUID of the first saved version of that card to llGetNotecardLine, and the dataserver event handler would llOwnerSay the retrieved data. When touched, it said "This is a test." Even though that first edit of that notecard no longer exists in my inventory, I can still get it through dataserver, since I recorded it's UUID.

Presumably, if I try that script again in a few days (assuming the garbage collection period is anything like that for baked textures), I won't get any response, since it would have been wiped by then.

You would have to obfuscate the UUID of the notecard within your script. From what I understand, the garbage collector scans scripts for UUIDs, but it cannot pick up things like NoteUUID = "030490234-09234093" + "-93843242-23498349";

oh ok... thanks Deanna Trollop that is interesting.

What's your opinion on updateable notecards, too much server load?

I think the main problem with this is griefers, inexperienced scripters or simple bugs in scripts which cause a script to edit a notecard repeatedly, adding just a single character at a time (or whatever), flooding the resource servers.

Imagine a script altering a notecard every time cycle... how long would it take before it servers bogged down from all the edits? Even if they put a sleep into the script that writes to the notecard, people would just use multiple slave scripts to do the writing to the notecard.

A griefer or some badly written code could very easily flood the servers with million or more notecards very quickly and very easily.

A couple of thoughts...

In 40 years of programming, here is a scenario I have heard a zillion times...

Outsider: Why don't you just do blah blah blah? It would be so much better.

Insider: Well, we thought about that, but it turns out that such and so would happen. It would not be better, and might even be impossible.

Outsider: Oh, yeah. I didn't think of that.

It seems to be that a lot of the ideas we read here in the forum are from people who have not really considered all the stuff the Insiders are privy to.

As for the specific thought about writing notecards...I think that is a misconception of what they are for. They are not general purpose files that applications read and write. Don't think in terms of the common paradignm: execute program, open file, read data, process, write data, end program (a very common paradigm burned into all our brains).

Notice that once an LSL script starts executing, it need never end, unless the object ceases to exist. So, once it has started up, why would it need to save anything externally? In the limited purpose world of object behavior, writing to files is irrelavant.

Of course it could be handy, especially if we continue to think in the old paradigm.

Instead, complain about environments where executables forget everything they know just because you stop them. In LSL, you can reboot the underlying Linux servers, and all your scripts (usually) continue executing from right where they were. For that matter, the LSL scripts get handed from one underlying linux server to the next, and continue to execute.

If I log in to a computer, why the hell isn't all my stuff right there, running, where it was when I logged off. For that matter, it should be there even if I login to a different computer altogether.

Lastly, try this: Make a Datastore object. It has a script that listens for requests. Any object can send it some data to remember, or can request to have that data back. Each datastore script can hold up to 16K, of course, and there can be a lot of them. You could even have them replicate the data to other Datastores for resiliency purposes.

This looks a lot like writable notecards to me Same purpose, anyway.

How about this?

Customer / User : I need to be able to do the following in order to meet my business objectives.

Insider /. IT person: Well, we thought about that, but it turns out that such and so would happen. It would not be better, and might even be impossible. blah blah. insert more reasons why can't be done in current scenario.

Customer / User : Oh. Well, that doesn't change my business needs or make them go away. I still need to be able to do it, because the current scenario isn't meeting my needs. If you can't do it, eventually I'll run into someone who can.

I think that when people ask for the ability to write to notecards, they are grasping at the closest thing SL has for storing data, and for storing parameters.

I see people now in desperation writing parameters to a prim's name and description. Just somewhere, anywhere, to safely store calculated parameters.

SL does need to introduce something like this. Whether or not one thinks it's a good thing if RL economy and biz moves into SL, it's pretty much a given that the lack of somewhere to store parameters and data records in SL is basically going to constrain its growth in that regard, anyway, and keep it in the field of a game.

>> Don't think in terms of the common paradignm: execute program, open file, read data, process, write data, end program (a very common paradigm burned into all our brains).

*But*, the reason people are thinking that way is simply because they have a need to do that, lol. So maybe notecards is the wrong word -- let's call them datacards or datarecords then, and introduce that? Or as you suggest, call it a Datastore object. Anything. Call it a peanut butter sandwich. We just need somewhere.

>> In the limited purpose world of object behavior, writing to files is irrelavant.

but it's not irrelevant in terms of the growing personal and business needs of people in SL, unless we are going to say that SL should remain a limited purpose world -- fly around, rez a poofer and buy a snazzy skin.


>> It seems to be that a lot of the ideas we read here in the forum are from people who have not really considered all the stuff the Insiders are privy to.

that may well be, but you know what happens in RL. A biz or org has all kinds of good internal reasons why they can't do something. And they are darned good reasons. But dang customers and users, they don't care, they see someone else who can do it and whoosh off they go. Ungrateful sods? Sure. But they won't hear you say that because they are already too far away.

As scripters we cannot change how LSL works, yes we can ask for feature requests but given the reasons already stated it will more than likely be denied.

Instead we work with what exists and extend or bend it to the point where it meets are immediate needs. What you seem to be ignoring is that there are useable alternatives, both in world and off world. Yes they take a little bit more effort to set up but they are here now and they work.

well 127 characters in the description field is not the same as a 64kb text file

html is request restricted, and can only deal with 2kb at a time, which if your going to save 64kb of data there goes your request allotment, and nevermind that it requires outside services to be available 24/7 forever by the scripter

that leaves rpc, which is similar to html, but it requires even more services to be maintained outworld

whats so hard about a stupid flat file thats

A already in the system

B already being fetched and transfered to the client

the main excuse from linden labs it that it would be too intensive for the system to fetch a notecard and save it again

well its obviously fetching the notecard, it knows where in the system it is, it knows its uuid, it knows everything about it, cept how to save it without creating a new file

whats the big freakin deal?

Right, so the specific "safety" here is that those script-writable attributes of a prim are persistent through script reset. For casual LSL hackery, these are kinda the easy options to satisfy that particular need. For real in-world commerce, though, this would be satisfied with llHTTPRequest and an external database. In between, there's the in-world but "outboard" dataserver, addressed by llEmail, with all the administrative complexity of server UUID management and cross-sim redundancy.

>> What you seem to be ignoring is that there are useable alternatives, both in world and off world. Yes they take a little bit more effort to set up but they are here now and they work.

(a) usable offworld yes; serious inworld alternatives to managing real data? I'm sure that's not what you mean

(b) as Osgeld Barmy said, "nevermind that it requires outside services to be available 24/7 forever by the scripter"; xcactly. I've heard many people say they won't buy x product from y person because if he loses interest and flatlines his website offworld, the product they're relying on to run their business is toast.

(c) "bend it to the point where it meets are immediate needs." Some might argue that the needs might have already gone past the "immediate."

(d) as Osgeld Barmy said, whats the big freakin deal about a stupid flat file?

we can probably debate amongst ourselves as much as we want whether having access to somewhere to really store parameters, and really store data, is a good thing. Probably no one here would say "no" to it if it's handed to them, but as Newgate Ludd says, "given the reasons already stated it will more than likely be denied.". And I agree, it probably will.

But as I said in a post a few up from here, just saying no to people's needs won't make those needs go away or stop people from going elsewhere to meet those needs. I'm seeing requests inworld from people who want search engines for their 60 thousand plus stock texture shops, want to establish wedding registries, etc, all of which require a way to tackle data. Maybe SL isn't meant for this and will never be able to handle it. But we all know IBM, as just one example, has all kinds of people crawling through SL and studying it. And *if* SL never offers a way to handle growing biz needs, and *if* in fact the demand for doing biz in virtual worlds continues to grow, well, there's nothing to say that SL won't just get left behind as people vote with their feet for a virtual world that won't deny such requests.

I ain't saying it's going to happen 2morrow, and I certainly don't mean this as hyperbole and for me to be interpreted as saying if I don't get somewhere to store a parameter I'm taking my marbles and going to There, Active Worlds, and Red Light Center. Part of the fun in working with LSL is working around its limitations so you can play with the fun stuff that it does do. And I want SL to succeed. We all do; we all have a lot of time sunk into it.

But this may all be a mute point. Entropia is on its way, and it definitely is aimed at being a "operating platform for business transactions." (Guardian. 2 June 2007. Watch out Second Life: China launches virtual universe with seven million souls.) We may all just be yesterday's news before we know it?

In various areas of life, we're all both newcomers and old timers, depending on the area. Some might be old hands in a kitchen and think nothing at whipping up a loaf of bread from scratch; some might be newcomers in the kitchen and uncertain why you can't just toss a cast iron skillet in the dishwasher.

Some said you can't make any money at selling tinned soup because it's so big and bulky that it costs a fortune to ship. Joseph Campbell came along and condensed his soup and the rest is history.

I found this message from last fall on the topic posted by Radar Masukami. I wonder if it isn't that on the one hand, you have the old timers so used to the idea that you can't, that they get a bit exasperated at repeatedly having to tell all us newcomers that you can't, and on the other hand, you have us newbies hearing all that, but still saying, "yeah, but how come???". grin.
______________________________
11-23-2006, 11:20 PM #5
Radar Masukami
Quote:
>> Originally Posted by Eloise Pasteur
lsl can NOT and almost certainly never will be able to write to notecards, or create them.

It just seems to me that the lack of real data storage is hugely limiting the variety of apps and really interfacing the web with SL. I personally can't believe it wasn't the first thing addressed when building LSL, it's so basic and required on the web these days.

Huge shortcoming.
______________________________

Just in passing, this is one application that would seem ideally suited to external storage. Even if the VM magically exposed wondrous search functionality, those textures and associated text-searchable tags are very valuable in any future virtual world; the business owner should want that data simultaneously searched and updated across multiple VR platforms. In this particular case, I would think this to be the core of their business, easily warranting a web hosting arrangement of their own.

It also raises the larger question of how much functionality should be internal to the VM as opposed to being handled by external processing. My initial take on this is that complex queries, for example, would be better done in SQL against an external database rather than with some to-be-developed in-world feature.

>> It also raises the larger question of how much functionality should be internal to the VM as opposed to being handled by external processing. My initial take on this is that complex queries, for example, would be better done in SQL against an external database rather than with some to-be-developed in-world feature.

I agree. In my own instance, I'm going to be shooting stuff off to be handled by IBM apps such as websphere and domino. Others may use php, My SQL, etc. To do this for yourself is one thing, though. To do it for others becomes more complex. For instance, if someone said they'd handle all my web processing for 50 lindens on month on an off-world server, I'd be like, hmm, given that you can't even pay the electricity to run the box for that amount, I'm not sure I'm confident that you'll be around for long. But if they quoted a more realistic price, like say 15 bucks for a cheapo hosting job, which translates to what, say, 4,000 linden a month, we'd likely think in Linden and go holy crap! that's a lot of money.