[sldev] Google Summer of Code 2008 update

[Kamilion]

On Wed, May 7, 2008 at 11:59 PM, Matthew Underwood <sakkaku at gmail.com> wrote:
> On Thu, May 8, 2008 at 2:31 AM, Lawson English <lenglish5 at cox.net> wrote:
>  > Matthew Underwood wrote:
>  > > What I really want (as an LSL scripter) is to have the ability to make
>  > > localized HUDs (like Vendetta Online and WoW, which use LUA) as it
>  > > doesn't really make sense to do all of the processing on the server
>  > > (as it is incredibly slow to update, particularly during teleports and
>  > > general asset loading on the client).  The downside would be allowing
>  > > people/customers to have the source or bytecode on their machine,
>  > > which could be problematic if people don't want their UI and/or
>  > > communications protocols exposed.   The transferring the data between
>  > > the two entities would be problematic, but something like an IM or
>  > > XML-RPC communications channel wouldn't be too bad.
>  >
>  > Well, please not XML-RPC, and while the current HUD browser (tutorial menu
>  > item in the RC) still probably isn't what you need, an interactive HUD
>  > browser that can handle flash or even SVG  (especially as found in the HUD
>  > inventory) would go a long way towards making your dreams come true.
>  >
>  > Lawson
>
>  While that would solve some issues, in the end that will be using
>  Email and/or XML-RPC so nothing is really solved.  In most cases that
>  would be actually slower then using an LSL object in world due to the
>  delay and increases the complexity immensely (some form of
>  authentication, user registration, tracking object/communication keys,
>  variables, etc).  While for simple items without dealing with the
>  actual object interaction that would be a major boon.

Seems like this would be a perfect time to point out:
http://wiki.secondlife.com/wiki/LSL_http_server
http://jira.secondlife.com/browse/SVC-1086
http://jira.secondlife.com/browse/SVC-913

By embedding a HTTP server within a LSL script, you'd get around most
of the problems of a clientside UI/HUD with a RESTful or SOAPy
interface.

With that, there'd be no need for llEmail or the choke-pointed XML:RPC servers.

Most of the authenication bits are covered with security-by-obscurity
by the format of the URLS:
calling llRequestHTTPServerURL() gives you
https://sim123.agni.lindenlab.com/cap/f23b4b94-012d-44f2-bd0c-16c328321221
which you can choose to either reuse, or call llClearHTTPServerURL()
and tear down the old server UUID and then llRequestHTTPServerURL()
for a new, fresh URL. 128-bit keyspace is large enough so
'keyscanning'/portscanning would be extremely prohibitive.

-- Kamilion
"Never feel stupid for asking questions, feel stupid for ignoring answers."