Feature Request: Load textures from HTTP without Quicktime/Media URL (Please discuss)

I don't understand why LL doesn't allow textures to be loaded from an HTTP link without using quicktime and the limited "Parcel Media URL". Why can't we just call

llSetTexture("http://my.site.com/image.j2c";

This would offload work from the LL servers, allow for huge amount of innovation.

Best of all, it would be *really* easy to implement, because HTTP cilent libraries are aviable on every platform.

Please comment if you like this idea.. I'm also submitting it as a feature request.

Felix

great idea, i love it, however, i see where LL would then loose alot of cash from people not uploading textures and just using scripts to set textures on everything.

This is technically possible, if LL adds support for it to the client. However, there's a couple things to keep in mind.

One of the goals of SL has been to provide an identical experience to the end user, no matter what computer platform they access the world from. In line with this goal, SL has to be able to deliver the same content to everyone in a standard way.

In the event that your web server stopped working, or was being lagged, or you ran out of bandwidth, then whatever textures you had stored on your own server would now be unavailable to anyone in SL.

With LL running dedicated content servers, you as the end user never has to worry about bandwidth and storage costs. You don't have to worry about your server going down.

While I can't comment on whether this scenario would be good or bad, but imagine. Over time, the various objects and other builds people create in-world load their textures remotely. Then people abandon their builds as they move on and stop playing SL. Gradually big parts of the world turn into big prim builds with a default "No image found" pattern all over. That could be very ugly after a while.

I don't think LL is making that much money on textures... but it might help them cover the server costs.

About the issue of a nice consistent experience. First of all, LL's asset server isn't exactly serving images all the time either.. given the missing textures on people (although that might be a different issue).

More fundamentally, the this kind of 'closed world' thinking is one reason why SL is not scaling very well. Early attempts to create the web had similar issues: they wanted to make sure that all links would always be valid... but you just can't do that in a large, distributed open system. If textures go away then people will clean up the objects. LL should stop trying to do everything themselves.

I think the benefits far outweight the costs.

Felix

By the way, to vote on this feature, go to

http://secondlife.com/vote/get_feature.php?get_id=2438

There's potential issue here with situation where person providing textures underestimates the bandwidth needed to transfer this data to users (which scales at least geometrically as the world size grows and the items using such textures find their way to increased number of people)

It's hardly reasonable to expect people will 'clean up' their 100+ prim houses when they find them missing textures because the original provider is no longer able to cope with demand or, like pointed out, simply moved on.

It's quite different situation from most of 'teh web' where you either get to visit a site or you do not if it goes belly up due to demand... but you don't actually *pay* specifically to view and/or 'own' the presented content. Double so because you can't also backup such purchased data for personal use in any reasonable manner, either.

edit: or to put it in another way, you can think of this suggestion as functional equivalent of direct linking to images posted on someone else's web page, rather than making local copy... because all copies of item(s) spread around SL ultimately link to that one original texture. Something that's discouraged and often despised/fought because it puts stress on original server that few can foresee and/or cope with. As LL is finding out themselves the hard way for that matter...

Its not that different from the web. Web sites can be swamped if many people link to them... you don't have to link to individual images.

Keep in mind that the SL and the web follow the "power law"... there are a few sites that get a lot of traffic, and a lot of sites that get very little traffic. If you are selling something that has custom textures in it, then you need to be willing to support the demand.

* Perhaps textures from links could be marked in some way, so that buyers will know that they are getting something that depends on a server.

* Or maybe you have to register yourself with the lindens first before you can make URLs to textures.

I don't care either way... I just know that SL needs to be more open to the rest of the computing world.

Felix

I think you'll have to stop there for a second and consider it for a moment before we go further into the 'sl is just like web' thing. While there may be some similarity between private sim with strictly private content and a web page, this is entirely overlooking most common aspect of SL content, which is items made and distributed around. To a degree you can think of them like common web page graphics which are distributed world-wide, with each single site using these things direct-linking to the original host. In this sense the 'power law' fails rather badly, because you have two separate distributions going hand in hand -- distribution of people around the SL, and distribution of items around SL. While with web it boils down to just distribution of people (visitors) over 'SL' (web sites)

And while yes, telling people "they need to be willing to support the demand" is stating the obvious, you are expecting people to grasp the concept of bandwidth use in world where the majority doesn't even understand why slapping different 512x512 texture on each separate small prim may be not brightest thing to do. With this sort of feature implemented without a thought you're only going to get sh*tload of content makers trying to link to some geocities page in attempt to save on upload fees, *lots* of broken content and a sea of people bitching loud and repeatedly at "dumb LL who can't even get the textures to load proper".

I think it is similar... just as content is copied around, links to pages are also copied around. If people like a page, then many people will visit it. If people care about their site, they will keep the content up to date. If not, the the links break. I'm just pointing out that LL is perhaps taking on too much responsibility here.

I think you'd have some many sites that load *faster* than they do now... texture loading is not very efficient in SL.

You didn't comment on my suggestions: for example, letting LL register users who write scripts that load URLs (not the owner of the object, but the creator). That way people who don't know what they are doing wout be "protected from themselves". ... ug.. but .this is the kind of paternalism that I think we should move away from.

Witht he curent setup LL can control the protection of textures far better than if the textures were on a web server.

If textures were being pulled from web servers then there is NOTHING stopping someone from sniffing the URL from the network and copying the texture outright. Take this to the next level with prims and the same is true.

Until LL figures out how to effectively protect content creator's copyrights they probably won't do much with the outside world.


*waits for LL to find the holy grail of IP*

Objects delivered from outside GRID:

-can NOT be trusted by default
-can be used for RL tracking (privacy issues)
-can not be restricted in predictable ways.
-creates inconsistency (sim is not in control how and in which order objects appear! this can lead even in security problems)

+spread load off sim servers
+add fast ways to change picture
+adds way to display dynamic content reflecting any RL changes


Trust and inconsitency can be tackled technically (example: objects deliveried from outside GRID would have to be signed by registered+ user; signature would have to be indentified in first ~2048B of object so it will limit possibilities for DOS attacks etc..)
Possiblity of future restriction applied by SIM on certain objects from OUTSIDE can be solved as well by defining types of objects at the beginning of payload (not like in the web where you can create JPG content-type and send javascript in it... strict one way of type identification at the beginning.

Privacy issue ... well that is problem which exist even now with media parcel.. but at least you have chance to switch it off.



As you see its not so simple to implement and needs more thinking.
If you would search in proposals you would see your type of request repeated.
Good thing about u is that you posted is for comments here

I guess we will see somehting like this in future but lets progress and not copy mistakes of old grandpa WEB from last milenium.

P.S.:IMHO Payment for uploading is mostly for missuse protection.

I'd rather see a way to "create texture from URL" Where the client would connect to the web, get the image, and then upload it to SL. That would solvve all the "bandwidth exceeded" problems and issues with hotlinking.

I'd like to see the upload fee removed.

It's great to find folks concerned with the matter of URL-sourced textures!

==>
For me, the dynamic content would be a huge deal because I would like to create flat panel displays that reach out to RL interactive map servers with URI.
As an application, I'd simply like to have a part of a wall in my SL house have a display that showed me a RL weather image or other map--and maybe a map chnnel changer control nearby.
<==

As for the risk of RL server sources being unavailable:
How about simply requiring that there be a Linden server-sourced texture for default (think plain white or golden wood) that will always appear until or unless the texture URL finishes imaging? That way, a URL texture could fail gracefully, ( and the SL market for textures would not be made redundant ;^)

>For me, the dynamic content would be a huge deal because I would like to create flat >panel displays that reach out to RL interactive map servers with URI
u can do it with media texture already... and user is also in control if he wants outside inworld sources displayed

I'd be happy with automated texture uploading that costs the standard L$10 each. That'd put a lid on automatic creation and still allow people to have external programs generate content.

Are you talking about self refreshing textures here?, if so then wont it put a far higher load on the SL servers, having to keep track of refresh times etc. Or worse making them have to respond to unrequested updates which could potentially be used as an attack path.

if it was still client / SL side controlled, i.e. request an updated image, then I think it would be more manageable, SL could throttle the requests as required.

>Are you talking about self refreshing textures here?,
As i understood it he proposed the same way as WEB used to do with lowsrc for <IMG tag.. or better example: text description instead of image in <img.. html page.

Similary he proposed that prim would have some default texture retrieved from SIM server
and then if available or if user permits , texture will be downloaded from non SL servers(untrusted)

I would add to that signing of outside textures by land owner' private key and it would be OK for me as a new feature

that would indicate auto refreshing data to me but I'll stand corrected.

I suspect there's also the risk of someone "pirating" a texture by pointing the URL at a site that isn't theirs or that they don't have permission to use. The owner will then find it very hard to trace this because the request will be coming only from a client or from agni, not from the person who actually placed the texture on the item.

I'd support this, IF it were treated like streaming media or Streaming AUdio

IE:

1. One feed per parcel
   
2. set by land owner
   
   OR
   
   
3. One feed per user (nor directly tied to land... be nice for a change)
   
4. feed cannot be installed on for sale object
   

Why? While a great idea to have a sort of auto-refreshing way to say, pull in a webcam image off the web (or whiteboard image, php generated snapshot of a webpage/chatroom, etc) I can see this concept being abused by "bad builders" trying to avoid texture upload fees. I can see it now, a full house built with dynamic textures.. refreshing needlessly. Worse, I can see that person selling their creation, and a month or so later, when the free-image-hosting place deletes his textures, a bunch of houses turn to plywood.

I would LOVE to be able to ressurrect my webcam, or desktop cam, or the "what's winter watching on TV cam".. or my ridiculously high tech "postit-note-cam"... but it's got to be something limited.

It WOULD be cool to be able to slap that feed image on something portable though, so I could walk around and "show" people something in RL.

I agree this feature would be great!