User:Zero Linden/Office Hours/Discussion
From Second Life Wiki
Now that Zero Linden's office hours have been underway, there have been several common discussion topics. This page is a place for those that want to continue the discussions longer term, or illustrate points with use cases, pictures, actual code, etc..
Contents |
HTML on a Prim
What're the chances of using uBrowser to replace QuickTime- before the year is out- relying on the user's browser plugins to play media, and getting rid of the restrictiveness of it QuickTime (e.g. Flash 5 only) ?
SignpostMarv Martin 09:15, 22 February 2007 (PST)
This has section has begun to get rather long. So I'm breaking it up into two sections:
- HTML on a Prim Taxonomy -- a full listing of different things this feature could mean and how it could be used
- HTML on a Prim Use Cases -- actual uses for the feature
llHTTPRequest()
HTTPRequest should support cookies at a region and or parcel level. This would enable users to authenticate to an external web application and communicate with it, accessing many valueable features and information currently available on the internet but not in SL.
For myself, this would mean allowing some of our users to login to our Learning Management System from SL, and check their status, access training content, and still be tracked for reporting purposes. As it stands now, I cant connect to my LMS because HTTPRequest doesnt support cookies which we use for user authentication sessions.
Added sept.18: During office hours Zero mentioned a concept of llLoadURLintoViewerMozilla where a script might be able to load say an authentication session cookie just into the viewer's browser. I think this would solve the issue for me, and honestly I dont mind the cookie remaining opaque to the script, it just needs to persist and be sent along with subsequent login requests (this is how it works in flash currently)
Tree Kyomoon 07:55, 12 July 2007 (PDT)
Incoming HTTP
Sean Linden has written a concrete proposal for incoming HTTP at http://jira.secondlife.com/browse/SVC-913
Summary from Discussion Log
A replacement for XML-RPC using an HTTP listener that would pass the path and body of a request to a script. Limitations of this would be that the URL would be tied to the region the object was (i.e. http://incoming.secondlife.com/Grasmere/12345678-1234-1234-1234-000000000000/foo/bar). A script could get the current object URL via a script call to llGetMyURL(). A caveat for attachments would be that the object URL would change on every region change, tying attachment URL's to an Avatar vs. a Region was mentioned.
Dynamic DNS?
If each SIM has its own IP address and the incoming HTTP proxy would run on a well-known port, then one solution would be to use dynamic DNS: the script would get it's current IP and then do an HTTPRequest to a dynamic DNS of its choice:
newURL = llHTTPService(...)
if (newURL != oldURL) {
string ip = ... newURL ...;
llHTTPRequest("http://dyndns.com/update", [ HTTP_METHOD, 'POST' ],
"domain: " + "mywonderfullobject.my.domain.org; " +
"IP: " + ip);
}
The incoming HTTP request would then be (using perl's LWP GET script here):
% GET http://mywonderfullobject.my.domain.org:WKP/UUID/....
(with WKP being the well-known port, and UUID being my obj's UUID.
With that approach, Linden Labs would not even have to operate the dynamic DNS service themselves, as everyone could use the service of their choice.
--Dr Scofield 09:16, 21 March 2007 (PDT)
Dynamic DNS will not work because multiple regions share a single IP address and will for the foreseeable future. If a proxy running on the simulator host is going to need to route the request to the right region anyway (or the remote app will need to know the port), we might as well run this service on the region domain web services hosts anyway; these will already have to know where regions are running and will have a load balancer in front of them. This eliminates the need for dynamic DNS and still allows the use of port 80. --Sean Linden 16:29, 5 November 2007 (PST)
Scaling Long Term
I'm not sure if this is the right place to post a request, but I'll try it here.
Because of the memory constraints of scripts and the memory leakage in dealing with strings, I have to store the objects I want to send via llHTTPRequest in notecards. Obviously, increasing the memory use of the scripts would have been one way of dealing with the situation
However, it probably would be generically useful if we could send an entire notecard via llHTTPRequest, so that it bypasses the script's memory. It might also be useful to then have more flexible notecard handling, though for my purposes it has been sufficient so far (that might change). This could be made more generic by have blob objects that could be converted to textures or notecards as needed.
Failing that, I had to implement a non-standard chunking method and a proxy server that took the non-standard chunks and put them back together again. Very annoying as it means that the server is now nonstandard and it's also not 100% reliable this way. I could have implemented my own standards-based chunking if I could have manipulated the HTTP headers. But that was also not possible.
So, if I had to choose between chunking functionality and sending notecards and/or blobs, I'd choose the latter. Give me an event driven XML parser and I'm in heaven. --Sifu Moraga 12:07, 22 February 2007 (PST)
Binary Blob in/out from SL
Background
During the discussions on 2/20 and 2/22, one of the basic themes was that underlying limitations in the LSL runtime environment limit the usefulness of sending large chunks of data to/from the SecondLife environment. In particular, the data space limitation of LSL scripts, prevents one from processing chunks of data greater than 2K-4K in strings. Further, the immutable nature of LSL strings limits a script to managing one or two large strings at a time.
A second theme, in many of our discussions has been to avoid making the current scale out problems worse. In particular, Linden Labs is concerned about solutions which place global, single point, non distributable load on the grid. Finally, note is taken about the total address space limitations per sim, namely that an entire simulator is expected to reside within 512M of memory.
Requirements
The basic requirement we are addressing is the need to get data in and out of the Second Life grid in a general, efficient and straightforward fashion. This requirement serves uses cases where off-grid storage, off-grid computation, is desired, as well as cases where off grid tools wish to upload content to the grid
Our requirements include:
- Import / Export of text files in size greater than 2048 bytes
- Import / Export of textures
- Import / Export of animations
- Import / Export of LSL source code
- Honor the SL digital right management rules
Note that all three requirements can be met via the first requiement, however, that would actually likely put more, not less load on the sims, as it would require LSL processing of the content to produce the desired items in the subsequent three requirements
Proposal
Provide a pair of functions which would permit the use of standard HTTP requests to provide a bidrectional pipeline for moving blobbed objects between the SL grid and external servers.
The basic mechanism would have a LSL script take an named object, from the inventory of the prim in which it resides, and ship it as an mime encoded object to a http server outside the grid, and in reverse, provide a pipe whereby a LSL script could accept mime encoded objects from external web clients, and store them into objects residing within the prim in which the LSL script was running.
The added functions would honor the SL rules on copy/transfer/modify. Ideally, the functions would permit the LSL script to have full control of naming during object creation. Well formed, mime types for the SL objects to be blobbed would be defined, and published.
