Blessed Be

This answer has prompted some inworld discussion of the mass hysteria, sorry, worshipful realization that http out lsl methods will be the salve that heals our ailing wora'uld.

I have to ask, if http is the answer to scripted data storage and retrieval, is it not equally useful for texture storage and retrieval? In other words, rather than upload and apply textures to surfaces, so that every texture has to be served by LL's Asset System All Hail The Central Asset System, we can enter a URL on the texture tab so that clients can download the file from our own servers.

This is just one example. Do I need to itemize seven more to clarify that this is not a single feature suggestion but a discussion of the flexible uses of http as a distributed method of data communication between our wora'uld and the real one?

Or am I making no sense here at all?

This kind of thing would not only remove Linden Lab from any copyright issues but also allow copyright owners a sure method for dating their material (so they can prove first use).

This kind of thing would also give us a basic, adhoc in-world browser; by using something like PHP to generate an image and an LSL command to change the HTTP query string that generated the image, we could display all kinds of information on a prim now.

This kind of thing would greatly free up the asset server and make Second Life much more of a distributed system.

This kind of thing would allow estate owners to maintain consistent, thematic environments; by changing one tree image on a server, your entire sim could go from a lush, green woods to a red-and-orange autumn.

One major problem with this: link rot. You think there's a lot of gray textures now?

Regards,

-Flip

Exactly. Activeworlds is a great example of this. They have special objects that you can program to display outbound image links. Obviously the world's a bit... old and decrepit, and web servers don't stay up forever. The result? Millions of square miles of broken textures.

Flipper, this would require dedication on the part of the publisher that's for sure. But now I have to ask, why are there so many grey textures out there now? Supposedly each sim has a squid serving the textures from a cache. Yet texture download seems slower now than it did when we were actually pulling them all from a single machine.

In all fairness, entering a URL on the texture tab would be optional to applying an inworld texture and would, ideally, be used for specific reasons such as the ones Jarod outlined. My point, such as it is, revolves around Kelly et al pushing us to use http to externally store and access data. If it's a good, the only, method for scripted databasing, it's just as good a method for other types of inworld data support.

What are some other ways we could use http to transfer data into and out of the wora'uld?

Maybe we shouldn't push this too far. The implementations might cause people to perceive the non-existance of the word'uld and ruin their immersion.

They could probably use the default wood texture as the in-world version of the famous "Red X" -- at which point, I doubt the world would look much different from how it does now with so many half-finished, untextured, long-abandoned builds littered across the landscape.

This might actually have the side-effect of having more themed sims. And imagine that at given times of the year, what flying over would be like. Decorations would change with the holidays, without ever having to add more prims.... And without hammering the asset server into an over-priced high-tech paper weight.

Blinkin' Nora, I absolutely love this idea. It's sparked off a ton of ideas

Khamon, where do I send the money if you can get it added?

Hosting textures and scripts and sounds on my own webserver = winnage

ya, the proposal system sucks but... see my sig for the relavant proposal.

edit: it occurs to me that some of you don't have sigs turned on so here:

Prop 889

Also, I said tga in there instead of jpeg2000 . Someone should make a proposal about proposals, ALLOW EDITING.

Nice, just used all my votes on it. I don't vote on the voting system normally, but I'm definitely eager to see something like the proposal implented.

They'd probably GOM you and host their own asset server.. Oh wait..

Plopped my votes into it too since they were wasting away in the proposal to finish XML/RPC ha ha ha.

There are? I don't recall running into anything that got permanently stuck on a loading texture that clearing cache and relogging didn't fix.

Jarod illustrated the point better than I. Just as the web is littered with dead links, the wora'uld is littered with unfinished plywood builds, abandoned builds with missing prims, and general clutter lying around on non-return land owned by accounts that haven't logged for months, even years.

If not wanting broken texture links is a good reason to not provide a clearly useful feature, then LL should be equally diligent to police the grid and remove long unfinished eyesores, to recover "abandoned" land, and to delete what appears to be left over clutter.

They're not of course. It's the landowners' responsibility to maintain their builds if they want to attract traffic, provide services et cetera. It's equally a link owner's responsibility to maintain the links. If they don't, as Jarod notes, there'll be little difference in the appearance of the wora'uld as those broken surfaces will revert to plywood just as they do now when a texture is made unavailable.

Besides, it's just plainly silly to axe ideas presented in a brainstorming atmosphere just based on what somebody might or might not do with it.

The idea is nice, but resolving a DNS name and opening a HTTP/TCP stream for 100 textures is expensive. This will only be made worse by half of the textures living on some low-rent sites which is either down or has a connection cap or a bandwidth limit. I doubt that in practice most scenes would render.

HTTP 1.1 added the "keep this TCP session open so I don't have to open one for each of the 40 images on this page" protocol bit because of the high TCP start costs; the proposed change would add that back in with the extra DNS calls. This works with streaming parcel music because you are opening only one session with the expectation that you'll be connected a while.

'Twould be better to fix the local cache or interest list or whatever allows you to log out from a fully rendered scene, log back in and see greyland. Until that bug can be squashed, do you really want the client to try to manage 60 pending GETs from sites all over the planet?

Having the client fetch "https://simfoo.agni.secondlife.com/$NONCE/UUID.jpg", where $NONCE is a hash of the UUID and some client-specific info to prevent replay attacks, would be a good idea. That would solve the "transferring textures via UDP is the worst idea ever" problem.

Having the texture be "http://my.freepages.com/coolimage.jpg", though? I don't like it, for the reasons other people have already noted.

you do have a point, however dns is already used by the current asset system, though it's probably just stuck in the hosts file on the server. local dns cache should let it work okay.

The open tcp session cost is incurred by the client I think it would be acceptable. it would also be acceptable to queue up image requests so the client only has to manage say 3 or so concurrent gets. I think it would still be faster.

Works for BitTorrent. Works for multi-tabbed browsing. Yes! I want my client handling as much as it possibly can handle. I have a 2.6ghz processor, 1gb of RAM, and a 3mbit downline; my home PC has more available resources per person than a given sim. It should be doing more work.

Reasons like: It would give us the ability to cuntomize textures on the fly? It would reduce the bandwidth bottleneck we face every day? It would put the responsibility on the developers to maintain their images?

Steering this back to Khamon's original point... What started this thread, I think, was my telling Khamon about Amazon's new S3 service. This is doing exactly what the asset server does, it's from Amazon so you know it's reliable, and people would only be charged by the giagbyte (so plenty of downloads before you get charged a Penny). Other companies are coming out with what amounts to web-based, "asset server" services. How much smoother could the world run if we were allowed to take advantage of them for more than just text?

No it wouldn't, because the client would have hundreds of textures within draw distance, so reloading textures more often than "when it's lost from cache" would be prohibitively expensive.replacing it with "I'm sorry, I've had to turn off the random wallpaper generator because I've gone over bandwidth 3 times this week and just got a bill from my ISP for $250!"I'm trying to figure out why this is supposed to be a good idea.

Add: it would make texture theft even easier, it would make bandwidth theft from SL a whole new game, and retaliation for THAT would be even more amusing. Imagine having the texture for your clothes being replaced by a cheesily UV-mapped goatse-style image.

Give it up Jarod. Noone is going to admit that pulling textures from alternate web servers can be used effectively in some projects some of the time. The idea will only be seen as an ill-guided attempt to take the asset server offline and implement this method in it's place.

That's what you get when you try to brainstorm here. Everything is argued from the simplistic perspective that we can't do foo because somebody might abuse it or because it would have to wholly replace our current method and that would be bad.

In all fairness, e.g. telehubs, that's generally what LL does; so the fear is well founded.

Thank you for trying to bring the thread back to topic.

It's easy to take for granted the texture bandwidth savings LL provides residents. All we ever pay is a one time charge of $0.03 cents and they pay bandwidth charges for that texture forever regardless of how much it is delivered.

Wouldn't this make it easier than ever to steal textures? Right click, Save as, Thanks for all the hard work. Unless we're talking about textures being somehow pulled through SL as a proxy, which seems horrid as well.

Edit to add: Missed that someone mentioned this earlier, oops.

Not following. What is it they would right click and save?

It's very easy to monitor web traffic on your own machine, and there are many many tools, free and pay, to do this. Assuming the images are hosted on public servers, it would be trival to find the url being connected to and go there directly in a web browser.