[sldev] Re: SLDev Digest, Vol 26, Issue 24

[Henri Beauchamp]

On Mon, 16 Feb 2009 16:34:00 -0700, Adric R wrote:

> llViewerSay sounds like the only sane suggestion I've read thus far.

You would not only need a llViewerSay() function, but also a viewer()
event, so that the viewer may reply to the script asynchronously.

Specification example:

New function: integer llViewerSay(key id, integer code, string message)

with:
- id: a unique UUID that would identify the vendor/application (so that it
  can be routed to the right plugin in the viewer.
- code: equivalent to the llLinkMessage() code parameter (i.e. some sort of
 "channel" number).
- message: the message for the plugin.
- the return parameter (integer): TRUE when the plugin exists ('id' is
  registered in the viewer), FALSE otherwise.

New event: viewer(key id, integer code, string message)

with the same conventions as above for the parameters.

And of course, a way and an API to implement plugins for the viewer...
Which is probably the most difficult part to implement since the viewer
currently does not offer any "hook" nor scripting mechanism for its
internal operations.

> > ---------- Forwarded message ----------
> > From: Marine Kelley <marinekelley at gmail.com>
> >
> > I totally agree with the idea of a llViewerSay (channel, string) command,
> > and would also support a llGetViewerString (string) to retrieve a string the
> > viewer would have set into the sim at login (exactly like what
> > llGetAgentLanguage does, but for arbitrary strings). That way the scripts
> > will be able to retrieve custom messages in a synchronous and secure manner.

What about:

New functions:
string llGetSetting(string name)
integer llSetSetting(string name)

which would allow to retreive and set the "debug" settings part of a white
list (or better: two white lists, one for reading permission and the other
for writing permissions). The white lists could be CSV lists stored in two
new settings (say "WriteSettingsWhiteList" and "ReadSettingsWhiteList") which
of course would themselves not be writetable via llSetSetting().

Oh... and llGetSetting() would also have to return special strings when:
- the setting does not exist.
- the setting is not readable.
while llSetSetting() would return TRUE for success (the setting exists and
is writable) or FALSE otherwise.

These two functions would cover the synchronous communication needs with
viewer extensions (such as RestrainedLife), at a low development cost (the
code to add is rather trivial, both server and viewer side), and would provide
scripters with a wealth of new possibilities, such as knowing exactly what
viewer version the scripts are running into, what display settings are set
or unset, what capabilities are available or not, etc: the default set of
readable (white-listed) settings could be rather broad without sacricifying
to security and/or privacy.

Henri.