[sldev] alternative os support?

[Peekay Semyorka]

Right now we have a Windows client, a Mac one, and a Linux one.  So in
this sense "bsd" would be another client.  But this scheme is only
appropriate when there is a 1:1 correspondence between OS and clients
(ie., before open source and third-party clients.)

Today a better definition of client would be "official_viewer", or
"myOwnClient".  A client might have other information associated with it,
such as a build version, a protocol version, the operating system it is
running on, client-specific info, etc.

So similar to a web user-agent, a client might send:

(being verbose here for illustration)

"official_viewer, v1.13.2.12, WinXP, protocol 1.13.2, en_US, digest
00fe234d2342123a523"

or,

"myOwnClient, build 1821, bsd, protocol 1.13.2, ko_KR, my extra note here"

Notice there is no correspondence between the official client version
(v1.13.2.12) and the custom client version (build 1821.)  Only they both
speak the same protocol level.

The server shouldn't care about all the other information, other than to
note it.

The server should only offer upgrades for official clients.  The server
may reject clients for advertising too old of a protocol (or some other
cap bits), or using the protocol incorrectly.  The server should not
reject clients for having the "wrong" client version.

We should have a standardized way for clients to self-identify.  Since any
client can advertise anything, such client-strings should simply be
treated as informational, aside from the advertised protocol level.

For example, functions such as "Tools -> Report Bug..." can / should note
the client-string.

The server can't assume because there is a security issue with the
official viewer, that same issue affects third-party viewers.

Which brings me to another issue. Right now security information flows one
way.  The community can report possible issues to the security email
address, but how do we in turn get notified of possible day-zero security
issues from Lindens?  We may need to patch our viewers for our customers,
before the issue is announced to the general public.

(In security practice we have coordinating bodies, such as CERT, which
work with vendor representatives to develop patches for each of their own
systems.)

-peekay