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.
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting privileges
