[sldev] SLDev Digest, Vol 28, Issue 1

[Maggie Leber (sl: Maggie Darwin)]

> From: Philip Rosedale <philip at lindenlab.com>
> Subject: Re: [sldev] Code review for those of you with commit access

> I want to help create a high-value viewer that lots of people use.  That
> means we can't just put every random thing into it, given we
> (collectively) have limited time and people.  Right?  So we thought
> stabilizing the new map code and getting that viewer out there was a
> good starting point.

We do hope to see people participating on the open-source side who are
also more-than-casual eaters of the dogfood. The map project resulted
in an improved map, but also broke some very high-quality in-world
content; when this was pointed out, the map project folk simply
shrugged and expressed surprise. "Gee, we didn't know anybody would do
that."

The technical debt that is incurred when you don't have stable,
documented interfaces and rich-enough services is: hacks like Lex
Mars' map texture UUID server, which was allowed to serve as a
de-facto response to a long-standing new-function PJIRA. The payment
you make on that technical debt is: you must have a better knowledge
of the use-cases that content developers and end-users see every day;
you can't fall back on a more formal API that lets you make broad
assertions about what dependencies content has.

Absent such architectural formalisms, the way you get the knowledge to
replace them is to spend time in-world looking at and understanding
things real people have done. Just hanging out with the gang that
built the last twenty shiny chrome deserted corporate islands may
teach you that "people are using megaprims and you have to support
them", but it won't expose you to more complex devices (more complex
than a notecard-giver or a conference table) that are in routine use
amongst the real residents.

Having a "high-value viewer" is vital. But the most sophisticated
viewer on the planet won't mean much without high-value content. The
number one complaint from the best scripters in-world is the
instability of the vaguely defined interfaces they work with. And as
plans to measure and ration scripting resources move forward, Second
Life will need even more to improve its retention of talented
scripters.

The viewer is capable of breaking content too, it doesn't all happen
on the server side...it's just that the most painful cases lately have
been on the server.