View source

== Some initial reactions to the architecture... ==

'''Disclaimer''': For those who don't know, I work for Intel. Although the comments are generally personal, I am participating in the working group as Intel's representative. I don't speak formally for Intel, but my affiliation certainly influences my position and interests. 

=== 1) Architecting the grid is not a once-and-done task. ===
 

In the meeting we discussed two primary motivations. The first is fairly
short-term: make it possible to scale performance of the second life
grid. The second is more long-term: lay an architectural foundation on
which virtual worlds (in general) could scale to millions of users
supporting a very diverse set of interactions (everything from WoW to
SL). Both motivations are very reasonable. But there is an obvious
tension between the two. In the short-term it is necessary to consider
the transition from the existing SL Grid though long-term scalability
might be best served by a more complete overhaul. It seems pretty
obvious that re-architecting the grid needs to be viewed as a multi-step
process not a once-and-done event. There will be lots of good ideas to
support a fully general, scalable grid that need to be put off for later
consideration (or we'll never make progress).


=== 2) Make our architectural "views" explicit. ===

There is tremendous value in having multiple "views" of an architecture
(for those who care, you can look for IEEE 1471 in wikipedia to get an
idea how to define views formally). In the meeting I heard three
different views presented. The "communication view" described the
architecture in terms Certified HTTP using RESTful interactions and
LLSD. Most of the detail that was presented focused on the "interface
view" or "component view". Each of the agent & region domains were
broken into services (with standardized interfaces) based on stateful &
stateless interactions. And we discussed a "transactional view" where we
hinted at how to sequence the invocation of various services to
accomplish a higher level task (eg the login example cascaded through
several different invocations... all of which were mandatory to set up
the correct state).

One view that was missing from the discussion was the "data" or
"document" view. What I mean is that we didn't talk about what the data
looked like, where it moved around the system, and how the various
functions transformed the data. I'm sure some of this will be derived
from the current grid architecture, but it still should be thought
through & documented. And of course there is the question (for the
long-term discussion) as to whether there are other standard 3D object
formats that should be adopted to encourage long term stability
(e.g. collada, obj, ...).

Just a couple more comments on the communication piece... Putting aside
my biases about REST... One question I wanted to ask is how the
architecture supports caching & replication. How hard would it be to
take the appropriate pieces and distribute them through something like
Akamai (or some other distributed web cache/content distribution
system)? Should the architecture explicitly include a separate CDN to
improve performance? This question is, in some sense, a question of both
the communication and document views. And it might impact how the
services are decomposed.


=== 3) We're missing a good functional decomposition. ===

Most of the architecture drawings that were presented focused on the
separation into region & agent domains. Clearly this is an important
separation for enabling multiple administrative domains. However, I
think the first structural partitioning should be along functional lines
(yes, the agent & region domains already capture an implicit functional
breakdown). Just to be concrete... I've been asked the question, by
several residents, why IM is so tightly bound to SL. There are many good
reasons to bind them (managability for one), but there are also good
reasons to separate them. In the case of IM, there are already a number
of very good and extensible IM systems such as XMPP (jabber & google
talk). 

A more thorough examination of the functions might help to figure out
which services belong in which boxes.


=== 4) Managing trust is going to be really hard. ===

It appears that transactions/patterns (such as login) involve services
in multiple domain. In the case of login, for example, the agent that is
created on behalf of a particular user executes services in a region
domain where the avatar is located. The agent domain proxies trust for
the user potentially across administrative domains. Proxying trust also
creates potential problems for tracking/controling where bits are
sent. This has impact in managing intellectual property. (Not that the
architecture needs to support DRM, but it shouldn't make it impossible
to provide some limits on distribution of IP.)