HTML in SL

I'm ... not exactly sure what your concerns are. The HTML code would be on SL itself, so how would it be "using someone else's PC"?

I think the security concerns depend on how much is to be implemented. HTML by itself is not especially problematic, being merely a formatting markup language. Javascript could be an issue. Flash or Java applets would have to be very carefully sandboxed. I would not consider using a system that allowed ActiveX, but as that's a proprietary system, I don't suppose it's very likely.

Probably there should be security settings as browsers have, to allow users to select the level of risk they are willing to accept. For example, most likely your browser allows you to decide whether or not to view images, execute javascript, run Java applets, store cookies, etc. These options would need to be implemented in the SL client.

I agree that further discussion of security issues around this is needed.

neko

I had a realization last night while talking with a friend about how people relate to SL and to the web. I am still very new to SL, and very aware of what it does to "players" and how they interact with each other and things in the world. The virtual world of SL is very real to our senses, and adding more realistic physics, via Havok 2 or otherwise, will strengthen the experience. For me, I don't require much suspension of disbelieve to feel I am there already. More physics done faster will make it more fun, more immersive, but already it is enough for me.

The dominant experience in SL is being there, making connections with people, feeling you really are there, and almost mind melding with them. It is a powerful experience that many of you have felt. And what do we do with our connections? Lot's of fun things, but one thing is that we share bits of information, usually lost to the ephemeral chat stream...

In contrast, the web is information first, with little or no feeling of being connected. In the early days of the WWW, people noticed the feeling of "going to a web site", and we still talk about it that way, but even though you are there, you are just a click away from not being there. And you don't (usually) see who else is there. The value of the web is access to the vast ocean of information, disorganized as it still is. The collaborative aspects are also valuable, but mostly limited to messaging, again with little feeling of being connected.

So what will be the effect of combining SL and the web, bridging the gap between information and connection? Will we be able to find each other more easily? Will web sites more to SL? I don't know if we can predict - the potential is enormous. Just remember how much the web changed the world, and multiply that by 3.

But what we mean by adding the WWW to SL could be very different depending on what features are supported. If the only feature we are talking about is static display of a web page on a prim, as if it were a texture, that would be a good start, but it wouldnt go very far. If we can make the URLs dynamically computed, that would allow a lot more, since it could be used to submit different requests to servers based on what the users are doing. But what about interacting with the page display? Can we click on links in the page, or invoke any of the other actions that web pages support? Click and keyboard events in SL must be translated into events on the web page to support that.

Beyond that, further integration of the WWW with SL is possible if the WWW browser is built into the SL client, not just a page pasted on a prim. It would be great if we could use JavaScript as the scripting language not only for dynamic web pages but for all SL objects. Then we could begin to dissolve the web page, make it an integrated part of SL, and vice versa.

How about making SL available on the web as well? An applet or plugin to the browser could provide a minimal UI with limited capability, enough to get more people experiencing the connectedness, and draw them into the full SL experience.

My guess is that the first step will be to have the normal browser live and running, and to write its window into the SL world so that it fits onto a prim, replacing chosen texture, as video does. Since that is probably pretty easy now, I would hope that the problems now being solved are to do with transmitting screen clicks back to the browser so that we can click normally on browser links, and surf the web normally, on the prim.

Thats what I think we'll get first. Without clickability it would be not much use IMHO.

The only way to use this facility to control in-world events would be (as suggested above) to use an entirely different route back from webserver to world, like email or XML/RPC.

So no script could directly access, and act upon, any data displayed in the browser window. It just wouldn't have access to it.

Thems my guesses at the most it would be realistic to expect in the first implementation. Anybody disagree ? Anybody realistically expecting more ?

... if HTTP: in SL happens, wouldnt that allow us to view web supported video that isnt QT supported (such as avi) on our prims now? Just a thought

All I want is the ability to send data via URL reliably and instantly to an outside php script via an LSL call without having to run through a bunch of SL communication hoops.

I don't care if there is full rendering capablity in SL. In fact less is better. No Java, no Active X, no Flash, just bare bones html, with the ability to define the destination URL dynamicly from within an LSL script with no delay.

GIVE US COM INTERFACES SO WE CAN EMBED OUTLOOK, EXPLORER AND ANY OTHER APP THAT SUPPORTS COM ON A PRIM

GIVE US COM INTERFACES SO WE CAN EMBED OUTLOOK, EXPLORER AND ANY OTHER APP THAT SUPPORTS COM ON A PRIM

I think you're looking for an entirely different feature then.

The description of this feature would be for rendering of HTML on a prim face, not for LSL HTTP interfaces.

I assume that there will be some abilty, via LSL, to determine the URL to render on the prim face.