[sldev] alternative os support?

[Todd T. Fries]

What does it really matter?  Anyone can connect and say anything.

Can't you just accept the os that is given and simply log it like a web server
does?

If the protocol is not spoken properly or the platform version is wrong, then
of course you can say `go upgrade'.

But why bother with anything else?
-- 
Todd Fries .. todd at fries.net

 _____________________________________________
|                                             \  1.636.410.0632 (voice)
| Free Daemon Consulting, LLC                 \  1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com             \  1.866.792.3418 (FAX)
| "..in support of free software solutions."  \  1.700.227.9094 (IAXTEL)
|                                             \          250797 (FWD)
 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
                                                 
              37E7 D3EB 74D0 8D66 A68D  B866 0326 204E 3F42 004A
                        http://todd.fries.net/pgp.txt

Penned by Joshua Bell on 20070123 15:14.33, we have:
| One current use of this handshake is to be able to say "there is a newer 
| viewer version available for your platform" - either required or optional.
| 
| * Optional usually indicates that bug fixes are available
| * Required usually indicates:
| ** a protocol change
| ** a client-side exploit was discovered/patched
| ** a bug in the viewer is causing content loss or DoSing the grid
| 
| Obviously, viewers can lie, in which case:
| 
| * They won't be told of optional updates - well duh, it's not an 
| official build anyway
| * They would be using an incompatible protocol - and stop working in 
| short order
| * They would be vulnerable to a client-side exploit - so update to the 
| latest code
| * They would continue to DoS the grid - but a malicious viewer can do 
| this anyway
| 
| As the Second Life ecosystem evolves I presume that some day the 
| viewer/server protocol will be open and stable enough that most of these 
| issues go away and that this sort of handshake is informational only. 
| And then some day this will hopefully be like the web, where the thought 
| of a web site telling you to upgrade your browser is anathema.  However 
| we're not there now, all but a small fraction of residents get their 
| viewers from a single source, and the protocol does change on a frequent 
| basis. So this handshake still makes sense.
| 
| We'll hardly ever do server-side differentiation based on viewer 
| platform. We have done this a few times recently when there was a 
| Mac-only fix - no point in forcing the Windows users to update. 
| (Following this thread, you'll see that we are currently unable to do 
| that distinction for Windows vs. Linux users - sorry!) Generally, the 
| optional/required versions advance in lockstep.
| 
| ...
| 
| So yes, we wouldn't add "bsd" to the list of valid clients, and should 
| instead evolve this handshake to accommodate viewers build by other 
| parties. Off the top of my head for short-term approaches would be to 
| add Linux (which for the foreseeable future will be the UN*Xy platform 
| targeted by Linden builds) and perhaps add an "other" token of some 
| variety that can be used to tell users who have built their own viewers 
| that the protocol has changed.
| 
| Opinions? What makes sense? What information should be provided in this 
| handshake such that a sufficient warning can be shown? (And consider the 
| scenario that you've built the viewer yourself vs. the future scenario 
| of having downloaded the viewer from a third party provider.)
| 
| Mathew Frank wrote:
| >Joshua,
| >as long as this is being visited, the following thoughts occur:
| >
| >   1. blocking access based on reported name of client is like
| >      blocking based  on reported name of web browser - ie useless in
| >      blocking access to somebody not using your official client.   It
| >      only leads to a misreporting of the client type - for example
| >      libsecondlife says it is windows when it is not.
| >   2. I see that you put this in so as to have an easy answer to
| >      potential problems.
| >
| >Accordingly don't just add "bsd" to a list of valid clients.  Replace 
| >the "denied access" system with a simple warning.
| >
| 
| _______________________________________________
| Click here to unsubscribe or manage your list subscription:
| /index.html