[sldev] Re: Thursday agenda

[Lawson English]

Robin Cornelius wrote:
> SignpostMarv Martin wrote:
>   
>> Rob Lanphier wrote:
>>     
>>> Hi SignpostMarv,
>>>
>>> I see you added a few items to this week's agenda:
>>>       
>
>   
>>>    * SL Viewer vs SLeek: accessibility for blind/partially sighted users
>>>       
>> Recently I've been forced to use SLeek as a means of accessing Second
>> Life- if I use the LL viewer, my system freezes.
>>
>> I found that the text-only interface would be hypothetically superior to
>> the LL viewer in terms of accessibility to blind or partially sighted
>> users.
>>
>>     
>
> Actually I ran across this the other day :-
>
> http://wiki.secondlife.com/wiki/Viewer_App_Cleanup#Lightweight_Client
>
> So it must be (or has been) on someone's radar internally. Page seems to
> be by Mani Linden with no edits since
>
> I think there are a whole bunch of reasons for desiring a "light weight"
> client. Accessibility is a very good one and I think it opens up some
> interesting design challenges. Although SLeek can be used now with a
> screen reader etc, it does not give very good scope for interaction with
> the world.
>
> Another good reason for some major re factoring of the client? if the
> protocol/communications was abstracted from the 3d render engine a light
> weight or heavy weight top layer could sit on the common foundations?
>
>   
Well, when you lok at the libsl code, which is a John Hurliman creation, 
it is dependent at the lowest levels on John's understanding of things. 
If he is unavailable for some reason, people have to use his code as the 
documentation for how things work, just as they do with the Linden Lab 
client right now.

The only REAL solution is to separately document the protocols and base 
any new implementation directly on those. If the documentation isn't 
correct or if the protocols change, then the documentation MUST be 
changed. The folks at libsl, OpenSim and me, for that matter, can't be 
expected to re-re-re-reverse-engineer the code every time something changes.

In the long run, having a single monolithic library to base things on, 
whether its for the LL official client, libsl, or OpenSim, should be an 
option, rather than mandatory. A TRUE lightweight client to handle group 
IM can be implemented in Python in, at most, only a few hundred lines of 
exceedingly sloppy Python code--including the code to log-in and 
establish a permanent presence on the grid--I know, because that is how 
I am testing my documentation of the protocols having to do with group IM.

There's no reason why a java applet used via a webpage  or plug-in to a 
mainstream chat client should have to use libsl or a Linden Lab 
equivalent to provide group IM to Second Life EXCEPT the lack of genuine 
documentation.

And if Linden Lab is serious about making SL something that can be 
presented to a standards body, that situation has to change.


Lawson