|
|
|
[
Permlink
| « Hide
]
Lex Neva added a comment - 12/Mar/07 10:03 AM
This would be useful. Until then, QuickTime will render most image formats as a one-frame "video", so you can do this in a limited manner already. An example is in the Suffugium sim. Over my Lex Labs store is a rendered text ticker that shows what's currently playing on the audio stream.
Quicktime hasn't been ported to Linux, so having a Dynamic texture ability would work out even better. llDynamicTexture([face,url,face,url,....]) maybe, with a possiblity of llDynamicTextureReload([face,face...]) for timed reloading? It would save alot of download time with the XyText script.
If pulling textures from unauthorized servers would be considered a problem, one option is to require that a special text file ("secondlife.txt" for example) resides in the same location. If it does, then the texture can be fetched. Such validated URLs can be cached and checked once a day or so. If the validation file or the texture file are missing, slap a 404 texture on the surface instead. (Might want to allow searching higher directory levels for the txt file, too.)
Once such a file exists, its contents can be used for additional features. For example, it can contain permit or ban lists as to who can call up those textures. Perhaps even to the degree of allowing any object with a creator of X or a owner of Y or any sort of relation to group Z, denying all others. Or allow all except anything related to P, objects created by Q, or things owned by R. I voted for this for two reasons:
1. It would reduce load on the SL network. Isnt it "HTML on a prim" feature? Requested and currently IMHO under development?
Remember what you are asking migth mean also that if I would have presentation to ~25 avatars Iam not saying it should not be done but HTML on prim would address it as well and IMHO should be done first as it adds ability to quickly put some html text from object script directly ... which is preferable due to synchronization and privacy (web server would not get user's IP). A 'dynamic web texture' is a lot simpler and safer than HTML on a Prim.
This one can be done quite easy. Tiger,
That's not a bad idea. It may not be much of a problem anyway, if we require the downloaded images to be sizes that are powers of two. Not many random images on the web would be the correct size, only ones made for SL. Concern about unauthorized image linking is admirable but unwarranted. How is unauthorized image linking from SL any different from unauthorized image linking from a web page? In fact, an SL region can only hold 40 or 50 avatars at a time, which is small potatoes compared to the load a popular website can generate. Besides, competent webmasters have ways of dealing with unauthorized linking when it becomes a problem.
Dynamic image loading was the first thing I thought of when I joined SL. The popularity of clever but inefficient hacks like XyText and QuickTime wrappers tell me I am not alone. I think this has been a long standing request with the SL, and I've seen it debated a lot by users. But, I would be eager to hear the Lindens opinion on the topic, which issues they're concerned with privacy/security/bandwidth/economic... It seems we all have a lot of steam about this, but we're blowing in the wind.
Linked to Meta-issue: Improved Privacy SVC-241. No way do I want my client making Web requests to non-SL random Web servers.
If the SL server made the Web request and then the SL server passed it on to my client that's cool tho since I stay anonymous and my IP isn't revealed to the prim owner. Aimee: have a look at the linked web page, most of it is about privacy. ^^
Easiest (and best I think) way of doing this would be to have the simulator download the texture so it can be served to other people more easily. It just needs to impose strict limits for dimensions and file-size, and possibly an alternative texture for if it can't be loaded in a timely fashion.
Aimee, your viewer already does this (parcel streams, web profiles, etc). You better log off SL for good, or accept that your IP isn't secret.
I changed the summary to match an internal project we've got going on and am going to link them!
Zero Linden mentions use cases for this work came from his inworld office hours. You can read up on the history @ https://wiki.secondlife.com/wiki/User:Zero_Linden To me web-on-a-prim is without any doubt the next big thing on Second Life as the possibilities are virtually endless if implemented correctly.
I believe Linden Lab has the following implementation possibilities sorted from easy to hard. 1. ONE WEB-ON-A-PRIM TEXTURE - NO INTERACTIVITY 2. "UNLIMITED" WEB-ON-A-PRIM TEXTURES - NO INTERACTIVITY 3. "UNLIMITED" WEB-ON-A-PRIM TEXTURES WITH INTERACTIVITY I read the WIKI page about it, and privacy issues. This is somewhat trivial to solve
HOW? Proxy, but not ANY proxy, use TOR. Embedd an tor client (& possiby server) into SL viewer. Example users: AnonymOS, uTorrent, Azureus etc. torrent clients. Torrent clients in together are the most visible uses of TOR network. Should be somewhat trivial, of course "network" testing of firewall needs to be done to some extend. Alternative options also needed:
What we have? Privacy protected for those who want it, and by default thru TOR network. Of course the other options does not give as strong privacy, and direct connection gives no privacy. Also, having TOR embedded into SL client ... Well someone could even make 100% private usage of SL as it would probably become easier to route all traffic thru TOR. JUST REMEMBER to put TOR on it's own thread / child-process / whatever, for minimal performance impact. Tor would be very slow. Couldn't we just put a preference for a custom local proxy for web textures, instead of having LL ship even more stuff? Those that want Tor can then configure it themselves.
The problem with web textures is that they make it trivial to associate IP addresses and accounts. Streaming media is much harder to do this with, because it's limited to a parcel - and people still run with streams turned off to avoid this compromise. User's web pages don't do this because there's no way to force a user to open a profile from in-world. Currently the best tool to tie users to IP addresses is by calling llLoadURL with a nonce.
Web textures would make using SL like browsing the web in a browser that let any web page fetch any cookie posted by any other site. If you came up with an amusing free scripted attachment that caught on you could basically map IP addresses to user names routinely, just by comparing the results of llSensor() with web hits. You could immediately link up everyone sharing broadband connections, and get a good guess at neighborhoods, and nail people surfing from work. Sure, right now really popular websites can do this... but they can't link them to identities that have any real value. Web textures would make it possible for anyone with a little scripting skill to do this, with the kind of reliability that's only been even potentially available to companies like microsoft and google and yahoo up to now. there should just be a transload feature for uploads, so for example i could tell SL to load a texture from www.example.com/foo.jpg .
then add a subscription option to pull the image every hour, which would cost me the 10L upload fee each time, and require no more traffic than if i were sitting there uploading 1 texture every hour. builders that want to use the dynamic textures would have to find a way to update objects to use the new file's UUID but this could be handled by player scripting. meanwhile everyone retains current privacy and the textures become dynamic =) This is included in 1.19.1:
http://blog.secondlife.com/2008/03/06/parcel-media-changes-in-1191-release-candidate/  I upload an SVG image to photobucket then display it inworld. How is that any different between displaying that image on a webpage, privacy-wise?
@jeska: the implementation in 1.19.1 is pretty awful. What about those of us who want to stream quicktime too? The feature included in 1.19.1 does indeed include the possibility to show a single URL picture on a prim.
But as it does only allow for ONE picture per parcel it is not a useful solution. We need to be able to show multiple pictures per parcel. What was hacked into 1.19.1 isn't what this feature is asking for at all.
This feature proposal was for web textures. llSetFaceURL("http://whatever", face), on arbitrary prims, regardless of parcel boundaries, regardless of parcel ownership. And actually, this proposal was for raster data only. All these features must be optional because they reveal your IP address to the owner of the hosting web server.
Using the internet reveals your IP address to the owner of every server you use. It's an inescapable fact of internet life.
I see no reason why people shouldn't be allowed to disable this if they would like though. (Devils advocate)
For most users the IP address is not important and not an identification anyway, its often dynamic and the closest it can identify you is to country and a specific ISP, but for others like me if you have my ip, with out much effort you can have a google map that says i work here with a big arrow, (and i am not joking here), but this may also be proportional to how "noisy" you are on the Internet Using the web and using SL are two very different things. You don't surf the web with an avatar that carries a specific name which is tied to RL information. Enabling web hosting by default is a breach of privacy. Even if you don't use it for large scale mapping of user groups (and then maybe selling that information), even my physical location,country and city, might be something I want to keep private.
"even my physical location,country and city, might be something I want to keep private."
Then what are you doing on the Internet? By posting on this Jira, you've revealed your IP address to a third party that Linden Lab contracts hosting of the Jira out to, and associated that IP with your avatar name. Do you know the name of this third party? Did you even care to look up whether they might be a reputable company before logging into jira or posting here? No, of course not, because IP addresses are inherently not private information, and the association of them with SL avatar names is not anything special or difficult to accomplish today. I should just harvest every avatar's IP address using tools available today and publish it, so we can end this silly debate. Nice idea .. but with LL loosing 10 Lindens for all those textures we upload to try, doubt it will ever be implemented .. loads and loads of little 10 Lindens uploads charges would be wiped off their "profit" line
I think it's a great idea. I am surprised it's not already implemented; imagine the amount of space and stress it would save on the asset servers if people didn't need to keep uploading stupid little textures just simply to preview something, or show someone a photo that they have no intention of using again. This wastes valuable storage and L$!
However, I can see this being bad for certain things, like prim clothing or attachments. People may use this ability to externally have all their textures, which they could change at any time, and cause content to break if their servers go down. I think it's more of a temporary thing - showing people pictures and up-to-date content without wasting the SL servers. It would be great for presentations, banners, adverts, etc. but not other things. Perhaps make it so the URL (external content) doesn't persist if the object is transferred to someone without a persistant script (potentially troublesome, although the alternative is probably worse). Even better would be if they implemented Adobe Flash on prim surfaces. Imagine the animation capabilities and even interaction and functionality! It would revolutionise presentation within SL. bitova, I don't think LL have put the L$10 price for textures as a way to make a profit. They've done it to cover the costs for the immense amount of space they require to store the textures. If people aren't uploading textures, they aren't needing the L$ to cover the increasing storage costs. Flash is proprietary, sorry.
Solution to LL losing 10L$ per upload for textures:
1) Make dynamic textures a creatable inventory item with an asset id. This item would have a URL property set at the time of creation. or... 3) Do like the rest of the web did and stop charging for textures then implement this request anyway. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Reopened
Major
Implement URL on a prim (i.e. JPEG on a prim via URL!)
