[sldev] Script to client channel.

[Lawson English]

Henri Beauchamp wrote:
> On Mon, 16 Feb 2009 01:13:00 -0700, Lawson English wrote:
>
>   
>> Both llTextBox and llFloaterHUD 
>> (http://wiki.secondlife.com/wiki/LSL_Browser_HUD) have one flaw, IMHO:
>>
>> they use the existing chat channels (which are all public) to pass 
>> information back and forth. Given that a HUD can only be used by one 
>> avatar at a time, it seems worthwhile to implement a set of private HUD 
>> channels that offer a direct HUD <=> client connection without 
>> rebroadcast to the rest of the sim. A given HUD could reserve one or 
>> more channels that can't be intercepted by other prims/avatars, thereby 
>> providing a greater level of privacy and virtually no chance of spoofing 
>> the server or client unless you have physical access to the network 
>> connections.
>>     
>
> What you do not seem to understand is that *all* the scripts only exist
> server side, be them inside a prim rezzed "in the sim" or be them inside
> a HUD (the HUD actually also exists in the sim server: it is simply displayed
> in a different way than "in-world" objects by the viewer)...
> As such, the data exchange must go through a "channel" between the server and
> the viewer and cannot stay local to the viewer.
>   
I'm aware of that. However as you say below:




> Granted, this "channel" could be something else than chat channels (via the
> messages passed between the viewer and the server), such as what llOwnerSay()
> (server to client) or llGetAgentLanguage() (client to server) do. This said,
> menus involve asynchronous communications (while llOwnerSay() and
> llGetAgentLanguage() are synchronous), so you'd need to implement this new
> "channel" in an asynchronous way as well, i.e. via a new event (for example:
> menu_input(key id, string name, string message) { }) and not via a function.
>   

Well, the http-in functions show a way to do this already, as do link 
events.  How difficult it would be to add a NEW channel isn't something 
we can know. I know http-in is taking a while, and CAP-based texture 
download is taking even longer to implement.


> As for privacy and chat channels, it is pretty good already, and spoofing is
> impossible, provided your scripts are properly written, which involves:
> - listening only to the avatar to whom the menu was presented (this way no
>   other avatar or scripted object can spoof the menu reply).
> - randomizing the chat channel at the time the menu is created (this way,
>   even the avatar to whom the menu was presented cannot spoof a menu reply
>   and cheat: great for combat systems, BDSM restraints, etc...).
>   


True but expecting folks to practice defensive programming is a sure 
recipe for people to NOT practice defensive programming...

Remember, Murphy was a programmer (a systems analyst for the military 
space program, actually).


L.