Today the second meeting of the Second Life Grid Architecture Working Group happened. This group (of which I am part of and which is open to everybody to participate) is working on protocol to interconnect Second Life Grids. The outcome of the group’s effort will be a document describing in detail how you can create your own server and hook it up to a grid (this can be but does not need to be the Second Life grid run by Linden Lab). Think Data Portability for Virtual Worlds.
Today Linden Lab invited to the second longer meeting for discussing the first draft of the protocol which was released earlier. Invited was everybody interested and it turned out to be a great and productive meeting. It was held inside Second Life using voice chat (the first one was a mixed reality event with people in the Linden Lab office and in-world. The audio bridge wasn’t working that well though).
We talked about many things like
- Are the right logistics in place? Do we need more or less meetings?
- How do people feel about the draft? Is the form ok, should it be different. How should the process of creating it be?
- Who is planning or maybe already active in implementing something for this protocol?
- What is Linden Lab doing?
- What are the phases in which the protocol gets written?
- What actually should be in the protocol and what should be separate?
All these questions were raised and we tried to come to a conclusion. So here’s Zero’s summary of what we discussed:
- the meeting structure is okay, maybe have better agenda and maybe have occasionally longer meetings with a special topic
- event queue: there have been some proposals for an alternative implementation, maybe XMPP?
- maybe we should do a meeting about transports at some point (to clarify: the problem is how the server sends events to the client because the server cannot initiate a connection because of firewall/NAT reasons. Thus the long-polling technique is discussed and actually already in use in Second Life. For more information look at this article by Jacob Rus explaining the techniques used for Comet.
- the planning of phases seem right with some exceptions. I will list them below
- L$ issues are maybe for a later phase. maybe optional and a separate standard. The problem is how to do micropayment.
- various projects for implementing this protocol are on the way, among others of course OpenSim.
- how do we deal with extensibility and baseline?
- what is the baseline?
- what can be opened up for innovation and evolution? (example avatar representation)
- also: how inclusive is the spec vs. how modular it is.
So there are also some open questions which need to be answered later.
I also brought up the point that we might need a good (and single!) name and a good/short URL so that one can tell people more easily about this project and they are able to google for it.
Here is what Mark summarized in audio:
Audio and Video
I also recorded the meeting, here are the two ustream Videos, below that you will find the 2 mp3 files with just the audio.
I didn’t work that good with the camera and the capturing region was somewhat small for whatever reason. Will try better next time :-)
But maybe the audio is sufficient anyway. Beware of silence though, I didn’t edit anything. Unfortunately I also had some gap inbetween because it stopped recording. But I think not too much is lost.