User:Finrod Meriman/AWG Feedback
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. User:Finrod Meriman/
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.)