[sldev] Re: More client forwarded chat channels.

dale at daleglass.net dale at daleglass.net
Fri Jun 22 11:25:12 PDT 2007


On Fri, Jun 22, 2007 at 12:53:41PM -0500, Argent Stonecutter wrote:
> >Having the viewer reply to the object isn't done yet, but the basic
> >idea is as follows:
> 
> For this design, would we even need this capability?
For this design specifically, no. But I'm trying to implement a general
solution.

Rationale:

1. This isn't an unique need. Other people will want something of the
sort. 20 different ways of doing the same thing is bad.

2. Chat messages are visible [1]. So any protocol like this must have
in mind that the standard client would just display it, resulting on
random junk on the screen. If multiple ways of doing this develop, some
of which have common capabilities, this could lead to scripts trying
multiple protocol, with multiplying amounts of junk on the screen as
result.

3. The best way to solve the above problem is coming up with a standard
protocol, which is usable for whatever is needed, then:

A. Get a patch that does the basic functionality accepted by LL, so that
any script can try to talk to the viewer without filling people's
screens with junk.

B. Have LL create an official system, with functions added to LSL to
support it. This would be the ideal case, but since we don't have server
code yet, it's not possible to implement without LL support. So I'm
taking option A for the time being.

Due to the above, I think a good protocol must have the following
characteristics:

1. Provision for versioning and extensibility. Must be possible to
update without ugly hacks or breaking existing functionality.

2. Simple enough for LSL scripts to use without complication

3. Generates minimum amount of junk in case it's not supported. Due to
this I plan to have some sort of registration request, which if
unanswered should be a sign that the viewer doesn't know what's that,
and that the script shouldn't try to make further requests.

4. Supports a mechanism to ask the viewer about what functionality it
can provide. This would help making user friendly scripts which can
figure out that the viewer's functionality is too old, or not present.

Notes:
[1] Yeah, something could be hacked up with the object changing its
description, size or something of that sort, but that's even uglier than
the chat hack.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070622/e39e7e46/attachment.pgp


More information about the SLDev mailing list