Offline uploads

I'd like to see the ability to upload images, sound clips, scripts, and notecards through a SOAP/WebService type interface, without requiring use of the SL client.

Image/sound uploads would still be charged L$10/upload, just like the client, or possibly even L$15 as a premium price. I would also suggest that scripts/notecards also require a fee if uploaded in this manner, even though it's not required to create/"upload" them through the client.

Here's the general idea:

<upload>
	<account
		first='Grim'
		last='Lupis'
		password='***Encrypted Password***'
		/>
	<item type='texture'>
		<format>BMP</format>
		<permissions
			share-with-group='false'
			owner-copy='true'
			owner-modify='true'
			owner-transfer='true'
			next-owner-copy='true'
			next-owner-modify='false'
			next-owner-transfer='true'
			/>
		<data>***Base64-encoded BMP file data***</data>
		<target key="***Avatar/Object key***" />
	</item>
</upload>

The target element would allow the specification of an object other than the avatar where the item should go directly into the inventory.

The response message would return the UUID assigned to the newly-uploaded resource, or a text message indicating a reason for failure:

<response>
	<UUID>***UUID assigned to newly uploaded item***</UUID>
	<Response>***Text response, such as an error message, 
		or "you don't have enough money" message.
		</Response>
</response>

Although I would definitely think that this should ONLY be available via HTTPS, due to the requirement to "log in." I would also suggest that users be able to set up one or more alternate passwords specifically for use with uploading resources dynamically.

The returned UUID would allow the uploading system to then use XML-RPC or SMTP-RPC to pass the UUID to an in-world object that will use the uploaded resource. It's the responsibility of the coder to store the UUIDs of resources that need to be reusable, so that they don't waste resources (or L$) uploading duplicates.

Scripts could be written/customized on the fly by an offworld sytem, uploaded, then PINned by an object that should be using the new script.

Notecards would be similar, but we would definitely need a few language codes to be able to embed landmarks/images into the notecard text.

<quezy>Html makes me quezy.</quezy>

endorsed

Boso, that's not HTML; Grim's talking in nice, juicy XML up there
==Chris

Please don't encourage price rises to further discriminate in favour of those with money. I'm already having to wait for the weekly stipend just to do things. Charge L$15 for uploading a script and that'll be 15 people fewer who get a rating.

Also, charging for uploading scripts discourages people from improving them through repeated testing and modification. It's not like textures, where the fee prevents abuse by discouraging the 10 trillion images of 1L from being uploaded. There is no equivalent script mountain that needs limiting.

Umm, that sounds cool. One question though, why do we need to upload scripts and notecards? Couldn't you just, uhh, copy and paste?

This was driven by the wish to use more powerful editors for development, since LL doesn't appear interested in improving the inbuilt editor. That implies needing to upload the scripts from the local gaming machine or from some other development box to SL, and ideally download them back down as well.

The clipboard is a very barebones and unhelpful way of doing this for scripts of any significant length. Ideally when you upload file Abc.lsl then you want it to appear under that name in some folder automatically, and ditto on download. Having to make a new script item, rename it, clear out its default contents, and finally cut'n'paste new code in, doesn't result in a rapid and error-free development cycle.

I would like a bulk DOWNLOAD feature!
Do you have any idea how often I have to save textures and scripts manually for offline editing?
Being able to bulk upload scripts would be nice to have as well. I often code offline when I am working on an especially large system comprised of multiple scripts.

Re-read my suggestion. Scripts and notecards created the way you create them now would still not be charged. Only scripts and notecards uploaded through the alternate interface would be charged.

As for why I'd want to do it... Modular programming. I could easily write a collection of code snippets/functions and build myself an editor where I could drag/drop "functionality" into a script easily, then upload the whole thing without having to log in.

Also, I could write systems that automatically generate certain scripts, with cifferent "constant" settings. (Variables named and used as though they were constants.)

I could write an AI that runs on a machine where I have more than 16k of memroy to work with, that would automatically create and upload new (limited functionality, obviously) scripts for its in-world interface.

And the list goes on.

Notecards would give us a way to persist data in-world by creating new notecards on the fly and uploading them as needed. Dynamic automated configuration changes would be possible, too.

The image/sound thing I think is obvious. It would finally give us the ability (if we could afford it) to develop a truly dynamic and interactive style of interface in-world. It's pretty easy to write an application that creates graphics on the fly, especially if you're only interested primarily in text or color changes to certain areas of the image.

The premium fee for usage of the service is to discourage people from going crazy with it and abusing the system just because it's there, resulting in overloading the data server and/or the asset server.

Grim, I like the various elements of the data description part of your proposal, as they handle many of the key issues very tidily. However, the hierarchical design that you've proposed is not all that good, as it mixes up the properties of the entities concerned. For example, the target is not a property of the item, yet you've embedded the target within the item descriptor.

Here it is again, restructured and without the login part which I think has problems (I'll explain "access" below), and also extended slightly with a "compression" element for those massive BMPs, plus another <item> block as an example. Notice that with this new structure, you can send multiple items to the same target inventory (which will be the normal case) without requiring the target details to be repeated:

<upload>
	<access	key="***Key of access-controlling object***"/>
	<target key="***Key of Avatar or Object with Target Inventory***"/>
	<item	type='texture'>
		<path>/Textures/Glass/FrostedGlass</path>
		<permissions
                        share-with-group='false'
			owner-copy='true'
			owner-modify='true'
			owner-transfer='true'
			next-owner-copy='true'
			next-owner-modify='false'
			next-owner-transfer='true'
			/>
		<data	format='BMP'
			compression='gzip'>
                	<base64>
                        ***Gzipped and Base64-encoded BMP data***
                        </base64>
		</data>
	</item>
        <item ...>
                <details of item 2 out of N in the upload>
        </item>
</upload>

The above revised design keeps the 3 sets of properties separate: the data being sent (with its inherent properties format, compression and base64 stream encoding), the item it will create (an object type, inventory path, and permissions), and the destination target that possesses an inventory.

As a side-effect, this has also moved the data element to the end which is good practice, because while the order is immaterial in XML syntactically, a SAX-type parser would like to apply all the validation before committing resources to full data handling. It's just a minor optimization for the boundary failure case, but it can help make the major case of successful validation more efficient by allowing the parser to avoid intermediate data copying.

Now let me talk about the problem of uploads needing to log in, and how this can be avoided. You mentioned the need for HTTPS, which indeed would be imperative if we're sending account and password details, since otherwise, bye bye to password security. However, in the vast majority of cases, the rest of the data does not need encrypting, yet the SSL layer will impose this overhead on everything. This is commonly known as "bad". In addition, the need for SSL will be a problem for some, and while not hard, certificate management will be an unnecessary bother for many.

There is another approach to the problem, much cleaner and simpler, and LL is already using it in XML-RPC: just specify the key of some upload-control object in the XML, and block all uploads completely unless that object permits them by previously registering its interest. This places you in total control, since you can embed any authentication procedures you like into your control object's event handlers. Note that the upload controller and the upload target can either be one and the same object or different objects, depending on the application. It's very flexible.

There are many ways to design the control mechanism. One very simple approach requires a single function something like

llUploadControl( integer uploadConstantsBitmask )

where the argument uploadConstantsBitmask is made up from 1-bit constants defined for each upload type, OR'd together as required. With this, individual upload types (or any or all of them) can be enabled or disabled with a single call.

If LL wishes to make a charge for some types of upload, this scheme makes it very simple to manage without requiring account passwords to be transmitted, since the key of the object enabling the access defines an account directly, and is in control.

Placing a charge on script uploads would be a dreadfully bad idea as I mentioned earlier, since it would discourage script quality and improvement since this requires repeated change and retesting. Furthermore, there is no script mountain in 1L that needs discouraging from uploads into 2L, unlike the situation with textures. Where uploads do get charged though, at least this scheme would allow users to ensure that they can disable uploads of a costly type.

Calling Grim, for feedback.

This is a great idea. It reall allows for a lot more automatic and server driven content to come into the world.

Perhaps an easier for LL to do this is to allow these objects to come into the scripts via XML-RPC.

This would enable a vast array of new functionality. I would almost think that the variety this could bring to SL for those that did it would be valuable enough to LL to allow uploads into scripts to be cheaper than their in-world counterparts. The more external server processing that is put into play, the less that the LL server resources are used.

-Zax

could just give us an FTP drop-box.

I don't like the idea of sending it through XML-RPC it would put to much stress on the server.

*stamp*
APPROVED

Well I explained already why a mechanism that requires remote login is a bad idea. Although this doesn't totally rule out mechanisms like FTP since anonymous FTP could in principle be used to upload the XML into a holding area for later injection into the world, it does mean that you lose entirely any possibility of interactive authentication of the incoming data transfer session through your own controlling object. You're no longer in total control. No possibility of dynamically arranging for different objects to receive the uploads, for example.

That would be a very very large sacrifice to make for the minimal advantage of using a fast transfer client. It's not as if you're going to transfer mega and gigabytes of data anyway ... well, GOM would love you if you did since they would earn an absolute fortune selling you L$'s to fund your transfer addiction, but us ordinarily mortals with thin wallets would just lose control and gain nothing.

Btw ...

Neither Grim nor I proposed that the existing XML-RPC link be used. We're merely specifying the data in XML as it's so versatile.

Having said that, XML-RPC could be used as long as a different target method than llRemoteData were used for the transfer, since the arguments to this method are not appropriate to this uploading, and it's best not to modify that old method since it's akready in use. A new llRemoteUpload method or similar could however be defined with more appropriate arguments for this. It would certainly save LL some effort, given that they're done most of the work already,

Sorry, I go through phases where I get annoyed with LSL and don't fool with SL for months at a time.

My thought when laying my schema out was that it could easily be extended to allow upload of multiple scripts/textures/notecards to separate objects as a single "batch."

When building complex networks, this would help alleviate the problem of uploading two scripts to two objects where the scripts are "synched" to work together, but one of them disappears into the black hole of the Internet, and causes the entire system to crash. Whereas if the entire batch disappeared, it would continue to function as before, just be missing a "patch."

But either way's fine with me, I just want to be able to create notecards/scripts/images through an automated system that I control and upload them via my account without having to do everything manually. I'm just shooting to get as much functionality into any initial implementation as possible, to avoid the "feature-fight" later on.

XML-RPC for scripts sure would be nice.

Please make sure to let us be able to set scripts on objects in other object inventories.

> Umm, that sounds cool. One question though, why do we need to upload scripts and notecards? Couldn't you just, uhh, copy and paste?

Ever tried copying and pasting 100 scripts? And thats just for a couple of days work on a single project.

I'd be rather partial of just having the abiliy to upload scripts via ftp, just like we do to our ShellServers. Its easy and fast.

Oh, and it should be free. (My ShellServer costs USD0.77/month with effectively unlimited ftp bandwidth).

Azelda

It's so we can build a fully 3rd party development environment