LSL Generated Notecards

Linden Labs has indicated that they will not create a LSL function that will allow the fully automated creation of Notecards because each notecard is stored separately in the asset server.

Thus providing a fully automated way of creating notecards opens the potential for a scripting mistake (not to mention deliberate attacks) to at the least congest and slow down the asset servers, or at the worst crash it (along with the grid.)

Kelly Linden, in response to a Second Life Answers question indicated that "an open webpage to be saved as an asset (be it 'notecard' or something else) by the viewer of the notecard may be a possibility" -- which I took to mean, that as long as a human had to be involved clicking a "save" button for example, that the creation of notecards by LSL would be considered.

There are many reasons why LSL programmers have wanted the ability to create notecards. Some of these include the ability to save configurations, or the ability to save data in one object then be able to load that data into another object. I do not believe an automated method of creating notecards should be used for these activities, and support Linden Labs choice to instead implement an object data store and better object to object communication.

However other uses include providing data export for human consumption, just a few examples include:
* CSV data to be used in external spread sheet applications
* Reports (Sales, Employee timesheets, Greeter Logs, etc)
* Mail merge type applications where your providing, for example, licenses or rental agreements

Linden Labs has suggested that "HTML on a Prim" or the ability to open HTML pages inside the SL client will solve this. Rather, I think this is offloading the problem to somewhere else rather then dealing with it directly. If SL is to be a viable platform for business, it needs the ability to generate text content programmatically, and allow users to store that data in a manner that it can be accessed within SL without requiring an external server, separate from Second Life.


My suggestion therefore is two fold:

1. Allow LSL to serialize a string to a temporary notecard, that is not stored as an asset, but rather displayed by the Second Life client locally to the user. The LSL function that creates it will also include a target UUID for either a object or agent. The temporary notecard as viewed by the user will have three buttons on the bottom of the viewer for
"Save to Inventory", "Save to [x]", "Discard." The save to [X] option would list the name of the object or agent provided to the function.

llCreateTempNotecard( string title, list contents, key target );


2. Optionally add a forth button or perhaps replace the two "save" buttons suggested in #1, with a "Save Locally" button. This would allow the temporary notecard to be saved to your local machine and not stored on the asset server at all. In your inventory, you will be provided with a third root option for "Local Inventory." The user could then optionally drag that into their normal inventory or into an object in world, at which point a SL Asset would be created for it.

For what it's worth...

/vote

Someone can probably elaborate on this more, but all objects in inventory (including inside objects) are individual instances in the asset database. Thus, if you were to allow a script to create a notecard, that would be another instance. Also, if a script could edit a notecard, each edit would create a new instance in the DB. Temp cards would be the same. This would be a huge load on the servers, and short from re-engineering their asset logic, this is probably just not feasible.

Now having user-rendered notecards could work, but I think that again would require some re-engineering of the client piece. Or maybe that's what you're calling for!

I have often looked for having a way to transfer data from SL and the RL and back again, and so far XML over RPC has been the only solution up until now. With the advent of llHTTPRequest though, we will be able to do this without RPC and email, and instead have all our data processing happen with php/mysql installed on a server. And nowadays, if you really need to get data to/from SL, you can just buy a domain for 10 bucks and a hosted php/mysql site for 5 bucks a month. That is totally worth it to me, and once 1.9.1 is released, I will be in SL-data-in-an-offworld-DB heaven!

I just would hate to see LL re-program stuff that works relatively ok when you (very soon) will be able to do it with what they have already developed VERY easily and quite affordably.

Hope these ramblings contribute somewhat.

MM

I concur about editting of notecards, for the same reasons you point out -- each edit creates a new instance.

A badly written buggy script could make a few hundred-thousand edits in a matter of minutes. Where as reading a notecard, editting it's content in memory (lists & strings) then generating a temp notecard that is rendered by the SL client but not saved as an asset, would only punish the scripter that made the mistake

Right now many objects use a similiar mechanism, where to "save" they have the object chat at the user/owner, and the owner must Cut & Paste the data into a notecard. This has IMHO significantly clamped down on innovation of objects in SL.



This is exactly what I'm calling for.

The primary part of my proposal is the introduction of creating notecards that are displayed to the user, but not saved to the asset server. Rather the notecards are either discarded, saved locallly, or with human intervention (clicking on a button or dragging from local inventory to normal inventory) saved to the asset server.

This would require introduction of a new server side function, modifications to the client code and introduction of code to push the data to the client. Much like the new Debug changes they recently made, except inside of writting to a "debug" channel, it would write to a "notecard" channel.



I too look forward to llHTTPRequest() and I plan to use it quite extensively.

But where it itches under the skin, and where I take issue -- is that for Second Life to be a "Platform" as Linden Labs describes it, you should not be required to use an external server for saving something like a log of who visited your property yesterday, or to record the results of a boat/plant/whatever show.

If SL is to be a platform, it needs to support the ability for textual data to be generated from objects and for that textual data to be accessible from inside SL w/o having to spawn an external browser or email application to view it. And certainly without requiring the use of an external server, no matter how inexpensive.

I'm not shy about using external server, I happen to be currently leasing my own dedicated linux server -- but SL as a platform would advance much more rapidly and be more widely adopted if it had mechanisms to store and retrieve object generated information both *inside* and outside of SL.

I have no idea how the asset server WORKS (no one does), but I think it would be possible for a script to have access to a *.txt file unique to it's existence (this is where I visualise the asset server as each object being a file inside a series of folders based on it's UUID, and grouping, etc.) that it could read and write to as per how simple C++ programs write to files (with the mentioned model, if each object is a folder of prims, then a script writing to a *.txt file on the asset server, each object (prim?) would have a text file, the script would call llWriteToFile(string str), scripters don't need to know what the file is called, and the fuction would merely write to "./file.txt" ('.' being "current location" (asset server location of the script) and "file.txt" being the file that the object/pim has read/write access to). llreadFile() would do exactly that: read "./file.txt" and return the data in the file (similar usage to the C++ function (which i can't remember off the top of my head), with ways to access the text by character, by line, by "word" ( the >> opperator in C++ terminates reading at whitespace) and as a whole (fail if text is larger than available script memory?).