I had recently a very interesting conversation with Greg More, from the Spatial Information Architecture Lab at RMIT. Greg is a really innovative person, sees the potential for virtual worlds, and does a lot of interesting projects around spatial data visualisation. Greg and his students have worked with different virtual world platforms.
In the middle of the lunch, as I asked him about Vastpark which he uses a lot, he suddenly said “Second Life is like writing in html, Vastpark is like coding in php”.
I found his remark fascinating, especially in the context of corporate companies usages. Collaboration is, so far, the main application of corporate virtual worlds, and both companies have made such announcements. Linden Lab launched its collaborative portal, and Vastpark opened the beta of 3C, its collaborative environment.
So far, Linden Lab has not released a new tool. Their collaborative portal is a marketing campaign aimed at presenting interesting usages of Second Life by corporate companies.
The architecture of SL is quite straightforward : one island is one processor, and users do have a set of tools to create content, which they own. Authentication is performed via a centralized server outside of the corporate firewall, a little bit like a telecommunication operator OSS/BSS. The client is open source, but not the server. In terms of API, apart from SAP which seems to connect to the reader and not the server, the only open APIs are registration, mapping, search, and some live data. Objects created are stored on the platform, and any duplication is done “manually”.
Well, this reminds me of the first e-commerce sites, where people had to manually transfer the catalogue from a database to full html web page. Pure hard coding. Then, came php, mysql, mashups, javasript, ajax, etc… And, suddenly, life became both much easier, and much richer.
Now, Vastpark. It is an open source product, made of 4 components, all downloadable (with source code as well): the reader, the creator, the publisher, the server. The reader, the creator, and the server are easy to understand. But what is the publisher?
The architecture of Vastpark is totally different: it is a distributed architecture based on components which can sit virtually anywhere. When someone creates an object, this object is published somewhere, and can be retrieve by any server, by any developer. The virtual world which is developed can simply access all the objects created, in a mashup type logic. Therefore, no need to duplicate elements inworld : duplication of the access is enough, as long as the objects are published (many already are on Amazon S3).
Another interesting point: everything can be described using IMML, an XML type language developed specifically for this purpose. Therefore, objects can be created “on the fly” just like php which generates html on the fly. In fact, it can be done in three ways: through its IMML markup, using a scripting language (LUA is currently supported but more choices will come) and through plugins (plugins may be written in any .Net language: Iron Python, C#, VB, etc). All of these can be written as components of remote widgets that developers can easily embed into their worlds.
In Vastpark, almost everything is a plugin. Voice control is a plugin. Avatar control is a plugin. We could even say that Vastpark is just a network which does interconnect plugins. With this respect, connecting the server to existing content is easy. A connector to Twitter, Flickr, eBay and Skype are already available.
This architecture is much more distributed than SL (who runs three server farms, one in Seattle, one in San Francisco, one in Texas). The partnership with Badumna allows to interconnect in a very efficient manner users world wide distributed.
We can see now the difference in the architectural approach: the component based chosen by Vastpark allows a greater flexibility, and a smoother integration into brand new worlds. As the virtual world projects mature, as more and more virtual world will integrate coorporate companies, this forward thinking approach makes all the difference.