Wanted: Your Questions for the HTML in-world Town Hall

In an attempt to better organize the Linden Town Hall format, we're now taking a group of questions before hand here in the forums, for those who may not be able to attend the in-world events.

Tuesday, June 21 at 3 PM PST, James Linden will hold a Town Hall to discuss all things relating to HTML inside Second Life.

Guidelines for Posting Questions:
1. Only one question per Resident
2. Questions relating to HTML in-world only
3. No Tech support-type questions (ie: "My computer is broken"
4. If you're interested in asking a question that is already posted - 'second' it instead of posting it again

I'll be heavily moderating this thread, so please stay on topic and post only the html-related questions you are interesting in knowing more about!

Thanks!

(more info on the Town Hall here )

In the long run (think HMTL on a prim), will textures loading from URL's download quicker on the client, than the current texture mechanism? Would this more distributed networks architecture better utilize the player's bandwidth?

Can we render HTML forms from a string and then get the posted results back in a list? Boy that would be great.

As a reminder, here's the text of what I posted when I accepted the feature on http://www.secondlife.com/vote/

Approved. Callum and James are working on this now. HTML in Second Life will be based on Mozilla technology. Mozilla/Firefox is cross-platform (PC/Mac/Linux) and does a good job of rendering almost all web pages.

Our goals are to support the following things:
* Browse a web page while running SL full-screen, for example, to see a home page, guest book, or wiki.
* Use HTML to put formatted text on the sides of primitives, for example, for signs.
* Load external web pages onto the surfaces of primitives, for example, for a status display.

We will be working on things in this order:
(1) static external webpage in 2D browser, no interaction
(2) static external webpage on prim surface, no interaction
(3) update URL for primitive, all viewers get update
(4) LSL call to set URL for primitive
(5) webpage from script/notecard/typed-in HTML
(6) interactive web page in 2D

The first release of web pages in SL will not support animated pages (Flash, blink, etc.). There will be strong limits on how many web pages can be seen at the same time, and how many web pages can be used on a given object, in a given parcel, etc. We have to do this because web pages take more resources to load and display than regular textures.

You'll be able to turn off the web page feature if you choose. Also, we may turn it off automatically on computers with 256 MB of RAM, because it takes an additional 30 MB of memory or so.

Update June 1: I don't know yet how much of the above will ship in 1.7. We may not get very far down the list.

Update June 17: We're focusing on (1) and (6) for 1.7, because we need it for help files, land auctions, script wiki, etc.. Web pages on prim surfaces may have to wait to 1.8. However, memory usage doesn't look so bad anymore.

James Linden

Question:

Has LL considered offering free webserver space for all LL residents? (Even if limited, like 10 mb?) LL could then offer direct, quick, HTML updating from in-world scripts / interface, and that would be insanely awesome. (A much greater level of SL <-> Internet interaction).

Excellent idea Hiro.

My only question(s) this time:

- What formats of plaintext/active scripts will be available in a web browser format? I'm not asking about animations here - I'm talking things like XML, ASP (sic), Perl and MySQL frontends, and Active-X Controls.

- Parallel to this question, how much of Mozilla's (Firefox) functionality does Linden Labs plan to take advantage of? Will the browser take advantage of pop-up blocking, cookie reduction, and similar features of the program to protect users? Will transmissions be protected from hijacking?

We currently are limited in what XML-RPC can do, since you can't start an XML-RPC transaction from in-world, except through llEmail.

Will this new feature be able to let avatars click on a prim with an URL which doesn't really display anything but invoke a XML-RPC call through an URL? What will you add in terms of delay?

The idea would be to avoid 3 or 4 popups like: "You have clicked on an URL-enabled prim. Are you sure?" and then "You're calling http://www.mywebserver.com/xml-handler.php?nextid=1897" and then "there is no output from the page" or something like that. I'd like to see a way to skip all those popups. Basically, the only thing that should exist in terms of error handling is checking if the avatar has given permissions for loading URLs, ie. if a llRequestPermissions(avatarKey, PERMISSION_URL) succeeds, no popups are ever displayed, even if the result is an "empty page".

Of course, to make it a proper entry point for XML-RPC, it would be nice to capture the result of the call into a string. This would mean something like:

llSetURL("http://www.mywebserver.com/xml-handler.php?somethingtodo", CAPTURE_RESULT); (alternative: NULL for displaying a normal page on a Find-like window, PRIM for displaying it on a prim's face instead, according to the selected texture, like on video streaming)

And catch the result with an event (say, perhaps a database event) where you would be able to get the return string. This is basically a way to get rid of all the llEmail() calls for XML-RPC usage.

Jeffrey, ASP == Active SERVER Pages... they're just Microsoft's idea of the CGI standard (Common Gateway Interface) that is accessed in a completely transparent manner and runs entirely on the server. CGI scripts accept HTTP POST through stdin, HTTP GET through an environment variable(QUERY_STRING), and dump HTML (or any other Content-Type you want to generate) to stdout.
Just like LSL, the actual code never reaches your client, SL will merely get the resulting content already generated and render it through firefox into a single image that can be put on a 2D window or on a prim face.

James:
What would be really interesting would be to have built-in support for CGI and HTTP.
Imagine, serving web pages off a prim.
Seamless web integration with LSL through HTTP POST/GET communication with the outer world.
Downloading an RSS feed into an LSL script. The possibilities are endless
Will we ever have any of that?

If this is indeed the case, then I will be interested in what measures will be in place to prevent hijacking of this stream. Or if like Quicktime, the stream is simply routed through the browser then output in the client, I'd like to know what degree of configurability/settings migration Second Life would support.

My original thesis is built on the browser functionality being built in instead of just run through a current install. I believe I've seen information to the latter, so you're probably more on point than I.

Hijack what? Are you afraid people will steal your URL or something?
What do you mean by "configurability/settings migration"? Importing bookmarks from firefox?
As I understand it, we're not getting a complete Firefox browser in SL, but more like integrating its HTML engine (Gecko) and retargeting it to render to a texture instead of a normal window?

For example, suppose someone (stupidly?) decided to access their bank account through SL. The question becomes: How will the feature be integrated? Would this person have to worry that this data is being transmitted "through" Second Life, or will it be safely cordoned off to a private stream on the client only?

And by settings migration, I'm talking things like Popup and Cookie Settings, Bookmark Migration, Security and Encryption settings, etc. etc. I happen to be a long-time user of Firefox, so naturally I'd like to know how customizable the interface will be.

After all, I run SL in a window expressly so I can multitask in the browser and other programs.

At any rate, I'm sure these questions can all be hashed into a single statement. I'm sure Jeska will happily add an "[Asks a lot of questions about X]" line.

moved to other post

there's going to be a 1.8 now?! I thought after 1.7 work was going to start on 2.0?

Jeffrey / Zepp, let me save James some trouble and point out that in the first 5 steps of development the websites will not be interactive - no link or button clicking - and in the 6th step only the 2D browser will be interactive.
There is no technical reason why HTTP POST would ever have to go through the SL servers, and any banking information you send over the internet is encrypted with SSL first... it won't be any different from having firefox in front of SL (when running in windowed mode).
The SL client will just download all the HTML for you, render it to a texture, and display it in a 2D window, or upload it to a 3D prim.

Is there a possibility that we could get basic text formatting functionality out of this? Basic HTML tags to format simple text messages on prim surfaces would save everyone LOADS of time, and I think would go a long way towards making better interfaces, data systems, and a whole bunch of other stuff.

I'd like that a LOT more than "super extreme web page browsing" functionality... who's going to shop at amazon.com while in their browser anyway? More people use image-based signs than watch movies on their land... let's get text-formatting in the game first, please.

LF

Will the extension interface be removed/disabled?
Will there be settings for http and https proxy?

optimaly I would like both, so I have my choise of using Proxomitron and GreeseMonkey.

So, wouldn't this basically mean that you can get rid of uploading for textures (and sounds if they are supported) and if animations are supported, could we interact with them? That would be so great ^^

I'd like to know where to load of "rendering" the HTML will actually occur... client or server side.

If it is server side great! Should mean no extra CPU time for clients and it would load like a texture? I'm curious if this would replace normal texture uploading.

Is HTML on a prim going to follow the model of texture or of video/sound? Will only land owners be able to put HTML on a prim and will it be limited per parcel or limitless and not dependent on land use?

Ideal application:

1. Creating on-line documents that can be read in SL in "book" form

2. Creating signs in CSS and HTML thus enabling more text signs with less photoshop.

3. Using a webpage image to avoid texture uploads.


Other Thoughts:

If someone makes a page.. and many people use it for a sign or texture, it will be odd to see 100's of "404's" in world


Filtering Viruses, Java Script, Sound etc...

I would imagine that the following model would make all users immune to web abuse.

1. SL prim requests page from WWW
2. SL reads HTML and converts the rendering to an image
3. HTML page snapshot appears on prim.

I would find this highly useful, but I think the point is missed as being about web browsing. I don't expect "HTML on a prim" to mean I can surf CNN while I build in the sand box. This means a ridiculous amount of bandwidth pull on SL. I would expect and desire HTML reading that is devoid of client side action such as Java, Javascript, and such, but takes full advantage of server side CGI and PHP.

I don't want SL as a web browser. I have one.

Web pages on prims are just going to be textures, and will never be interactive?

I'd like to know what new LSL syntax will come with this. Will it be possible to specify a browser window's size and position from LSL, or the webpage itself with JavaScript? Will the 2D browser interface be configurable from LSL, i.e. will it be possible to make a script open a window without forward/backward buttons and such?

Ooooh, would there also be a built in Firefox that can be opened from a tab at the bottom? That would save system resources letting SL run better thus my computater wouldn't lag as much... hopefully...

Like Lordfly, I'm much more interested in HTML as a way to render text on a prim surface in-world, rather than the interactive, internet access part.

Can you give us an idea of how HTML on a prim will work in terms of LSL? Not the actual calls, but what we'll be able to do. Specifically, I'd like to be able to grab HTML from a notecard and render it on a prim face (HTML as texture). Or would we pass a string to a llSetMarkup() call? In either case, being able to use CSS from another notecard would be a big win, especially if it can be via UUID, so I can manage formatting w/o having to update notecards everywhere.

Seems like there will need to be some viewport transformation magic to allow HTML to render on a prim face. Will we be able to use scripts to scroll around? It seems like we might need finer control than the current texture scale/offset settings allow.

Disagree STRONGLY.

Servers are already lagged. There's no reason to load servers down with rendering an almost infinite set of possibilities of text, images, and content streaming in real time into a texture and then broadcasting that to a client. Mozilla has been proven on Windows, Mac, and Unix, and there's no point in reinventing the wheel.

It's also in many cases far more bandwidth intensive. Compare transmitting a few kb of text vs. trasmitting a stream of an image, in BMP format as to not make the text unreadable. That's just a silly waste of bandwidth.

Also, when we do integrate more dynamic elements, like video / flash / Java / hell, even basic pull-down menus, it'll be crazy for LL to be streaming that in real time for every webpage in view.

And on top of that, data still resides on a remote webserver. Why pull it all the way to Linden Lab, render it, then send it to the client, when you can just establish a connection and have the client download it directly from the source? We're talking major propagation hit on start of the download, + 2 paths of bandwidth in/out of LL as opposed to none, + the above issues.

All for what? Saving a few CPU cycles on the client end? Don't be silly.

The only thing I could think of doing it server side would be security.

Agreed... I think pulling things from a remote server or a series of remote servers will be quicker than relying on one server that becomes a bottleneck. Think Bittorrent.

Thanks for the questions, see you tomorrow!



Edited: Check out the transcript here