[sldev] alternative os support?
Joshua Bell
josh at secondlife.com
Tue Jan 23 15:14:33 PST 2007
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.
>
More information about the SLDev
mailing list