The basic way this is handled, is through the new ‘IClientCore’ interface. We introduced the IClientCore interface within a few hours of version 0.6.0 being tagged - however switching to the interface internally will take some time - probably a month or two, so any projects using IClientAPI are still safe.

As many of you who have played with writing region modules will know, IClientAPI represents everything you can do to every possible client - as one may guess, this doesnt scale when you begin adding multiple different clients into the mix. It also makes things difficult when two clients have the same feature in radically different ways.

As you can see in the diagram above - all the particulars of IClientAPI are bundled up together as one common interface. It is convenient - but it’s also problematic when it comes to implementing a new client, as you need to stub out every single function - and modules cannot tell whether a particular event or function was simply ignored by the client as unsupported.

Enter IClientCore

IClientCore is presently a very narrow interface - we’re defining it as everything a client must support, whether it likes it or not. As a consequence - we’re sticking to things that every single client has and implements in a common manner.

In practice - this means IClientCore dictates only the Name, ID and other very common internal parameters. It also needs to support two new ’special’ interfaces - Get<IFace>() and TryGet<IFace>(IFace out). These last two are the keys to how the new system works.

Under the new system - we implement interfaces for Chat, Primitives, and each seperate functionality group. It’s then possible to use, ‘IClientCore.TryGet<IClientChat>(…)’ which returns an interface to this clients IChat interface. If the client doesnt support chatting - then TryGet returns false.

The first most obvious question to arise here is related to how this looks more complicated than it used to be, and that’s definetely true - where we differ is that the new model means you need to check a client supports something before attempting to use it.

Previously we had no way from modules to indicate whether a feature was supported on clients - and we also had no way of handling extensions. This also means that if you choose to implement a new Client adapter for OpenSim, you dont need to implement the previous 350 functions and ignore any custom ones. You can write new interfaces for your custom features, and only implement interfaces from the Linden Viewer where you think you share enough functionality to make it useful.

In most cases - the changes arent fairly significant, you can see a comparison of two functions under the old and the new in the porting guide I wrote.

If anyone has any comments or questions relating to this, please let me know.

Previously…

For those who havent been reading up on the OpenSim IRC channels or mailing list, your probably not aware of the work we’re doing at DeepThink for the realXtend team.

For the last month and a half, we’ve been working with the realXtend team to convert their version of OpenSimulator, to something that closer resembles a suite of OpenSim plugins rather than a fork. Part of this work has been some sponsored contributions to improving the modularity of OpenSim itself with alternate clients (like the IClientAPI changes that are currently in progress), the other part has been conversion of the current realXtend server into a single plugin DLL called ‘ModularRex.dll’ which encompasses all the previous internal changes.

The single biggest bit of news however is, once this is done - realXtend is no longer a fork of OpenSim. It’s not opensim stock, but it’s not a seperate codebase either. Patches from realXtend can be applied fairly smoothly towards OpenSim-trunk and vice-versa, because the core files are unchanged.

Now we’re not done yet, but we’re making some pretty steady progress to getting there by the end of the year - today marks the date at which the core architectural bits and pieces are mostly done and the realXtend server developers can get onboard and help finish the rest.

The code for the modular rex DLL’s is located on the forge project for it. It may not always represent the latest testing versions (since we’re working offline a lot), but we’re doing checkins every now and then - if you’re interested in following progress, that’s the best spot to go. Future development will be going on on the forge exclusively however.

Multiple Concurrent Clients

One of the largest feature’s we’ve now got with the latest version is the ability to insert clients into the scene while bypassing the normal login routines. This may not sound like much - but the technology needed to support this, is the same technology that will allow you to login with two completely different virtual world clients and have a conversation between them, while viewing potentially the same content.

The new ModularRex code skips all the current login methods and actually has a new subclassed and derived version which it enables entirely through a shared region module. In future - we may be able to take this same methodology and convert the current login and protocol handling routines into their own modules which allows them to be replaced without effort.

ModRex Support Table

Features

• Rex Avatars - We support all the packeting for the avatars now, however we do not automatically send this on login yet. If you know your rexav address, you can just type “/rexav http://somewhere.com/myav” in chat to set the parameter manually - or you can wait a few days now that we have login implemented and we can get to setting it automatically.
• Rex Logins - You can now login with a traditional rex username, that is you can login with “username@hostname.com”, and your authentication server will authorise you instead of a direct login.

Infrastructure

• Rex Packet Handling via RexClientView - We implement a IClientNetworkServer compatible interface which deals specifically with the modified realXtend protocol. This is subclassed from LLClientView / LLUDPServer / LLPacketServer but contains overrides and new methods to represent realXtend features.
• Rex Methods and Events on ClientView - We now process a number of the realXtend events and packets and fire new ‘OnRexXYZ’ events that you can use to send specific things to users. This does not effect IClientAPI, rather these are members of RexClientView which means you need to check the client supports features before using them. Currently, we’re sitting at about 13 of 36 handlers - however we’re 13/13[?] if you exclude methods related to RexPython (as of 0.31, there are likely going to be new things to support with the upcoming Rex release).

The TODO List

• Conversion to IClientCore - We started a lot of the conversion work before 0.6.0 was tagged, this means that the realXtend modules use a older method for checking client capabilities. We need to convert it to the new IClientCore interface to allow us standardised access to extension capabilities in modules.
• Finish SceneObjectGroup/SceneObjectPart Overloads - We’re inheriting and extending from the SOG/SOP interfaces to add additional rex-only properties to objects. There’s a degree of difficulty involved here which may nessecitate additional metadata fields in SOG/SOP. A post to OpenSim-dev will be coming shortly no doubt with some suggestions there. This is needed to be able to get rex meshes and other special object features working.
• Provide RexCommsManager - One of the limitations right now with the modular rex code is that Rex Logins (see above) dont provide a valid UserProfile class, because the Rex protocol there is different to OGS1. We need to provide an additional comms manager to allow Rex avatars to be handled correctly, or abstract OpenSim to allow ClientView to indicate the type of CommsManager it needs. This will also allow the global inventory features to be re-enabled (however moving them to the client may be a smarter long term move).
• Write generic LibRexAuth - A problem with the current dealings with the authentication server are that they are fairly hard coded for specific features. It would be nice to add a library or static class which can provide simple functions such as ‘GetProfileByAccountName’ or ‘IsUserAuthorised’ - this allows us to communicate better with the authentication server, saving hassle and headache and centralising things so that problems are more easily fixable. A similar class may be useful for the avatar server - however the simulator’s dealings with that server are very limited.
• Python - This needs to be converted a module, but shouldnt be too difficult as most of the code is presently abstracted and modular. With a little bit of work it may be possible to make realXtend python scripts editable in a similar manner to the LSL/C#/etc scripts, which would be very cool.
• Voice - As with the above, the Rex Voice Daemon is fairly seperate from the main codebase, so porting this should be a fairly quick and painless job.
• Update protocols to 0.35 - We’re currently sitting at the 0.31 release of realXtend which means there might be issues when the 0.35 realXtend viewer goes mainstream.
• Minor bits and bobs - Getting things such as the ODE Mesh Collisions working with realXtend collision meshes may nessecitate some additional work (and probably a subclassed version of our current ODE DLLs with additional functionality). There are probably a number of minor features and fixes that will need to be ported over once the main items on the TODO are done.

So overall, we’ve still got a lot of work to do - but the great news is all the architectural bits are just about done, and we’ve proven that such advanced functionality can infact be done entirely with the current OpenSim region modules.

This is a proposal - it is not beyond reproach or comment.

The Current Model: SceneObjectGroup

Let’s begin by describing the current model - the largest limitation enforced on the current model is it dictates a method of heirachy which is fairly constrained. You have a parent who contains all the properties of the children, plus a few extra, then zero or more child primitives who are linked directly to the parent. The combined whole forms the ‘object’.

When you wish to modify a group property from a child, you need to check if you have a parent, if you do, modify the parent - but beware, certain things like the Position property mean different things as a child or root (why we also have AbsolutePosition and OffsetPosition properties to avoid confusion).

The obvious downsides of this approach are - we’ve made decisions that indicate that heirachical linking will never happen (something clients such as VastPark support via their nesting methods), neither is it possible to not have linking at all (ie say a standard Torque game). We’ve also got a mess of message routing which results in a very large number of if-null checks that perform different tasks depending on the outcome.

What should a revision also contain?

As part of the opportunity to fix this set of classes, we’ve got a chance to fix up some problems with SceneObjectGroup and SceneObjectPart - among them are, Vendor Neutrality (SOG/SOP is highly vendor specific), Multiple Linking models (ie not just Root->Children)

Strengthen IEntity - Derive More.

My personal favoured solution to this problem is to go back to IEntity and strengthen it up a bit. Right now, IEntity is a very minimalist interface dictating almost nothing about entities within the Scene, but it doesnt nessecarily need to be.

There are a number of properties which we can dictate as being universal about every entity regardless of the virtual world platform - these properties can be deemed as appropriate for a core interface, off the top of my head we can say the following are true of every type of ‘Entity’ we want to implement.

• ID - The internal number used to indicate the object ID.
• Position - The position of the entity inworld.
• Serialised Version - A version of the object which can be imported/exported easily (XML?)
• Physics Shell - The bounding box or triangle collection of this collection.
• Name?
• Scale?
• Rotation?
• BoundingBox?
  
• etc…

In the case of the Linden model specified above (SceneObjectGroup), the container becomes harder - we access our information about the object collection via the container. Physics shells are given for the container rather than every object inside, etc.

It also becomes possible to have multiple seperate models sharing the same scene simultaneously, each shares and communicates via the properties on IEntity. As a result, the scenegraph then resembles something like this.

A part overview

IEntity - Basic building block of objects contained in virtual worlds, it contains only properties which can be considered common to every virtual world platform.

LLEntity - This forms a replaceemnt for the current SceneObjectGroup, it contains properties which are applicable to the entire object, such as Owner, Permissions, Position and others. It contains a list of Children in the form of LLPrimitive. Unlike the current SceneObjectGroup, we do not utilise the .Root property from children to store group parameters. For instance, LLEntity.Root.OffsetPosition does not dictate where the entire object is located - as the root object, it will always be [0,0,0].

LLPrimitive - This contains a replacement for SceneObjectPart, unlike the current SOP it contains properties and methods only availible unique to the individual part. Properties which are shared among the group should be members of LLEntity instead. If you wish to access a group property it is always and only availible via LLEntity, and there are never members of LLPrimitive which simply act as ‘pass-thru’s to LLEntity. If you wish to access LLPrimitive - you must always access it via the parent group, it cannot be accessed via Entities directly.

XYZEntity - This is another entity from another world platform, it may have a heirachical linking situation where multiple entities in scene are chained together and share properties between each other internally. To the OpenSim perspective however we only see multiple seperate objects.

Potential Other IEntity Derivatives

In line with the above stated goal of supporting greater vendor neutrality I would like to propose some examples of other representations used today, and how we would be able to implement them under the new scheme mentioned above.

AWEntity (ActiveWorlds™) - While I’m not proposing to actually implement a AW Clientview, it’s representation of objects in scenegraph is fairly common and very similar to how game engines handle them. In ActiveWorlds, the world is a semi-finite plane divided into ‘cells’, each cell contains a number of objects however objects cannot link and have no notion of heirachy.

To implement AWEntity - we would implement all the common IEntity interfaces such as Position, Rotation, ID, etc. Then we would in addition implement some properties for the AW object parameters (Mesh Name, Object Name, Description, Client Script, etc).

We do not need to implement anything complex in terms of parents or children and the classes are without such properties. They contain a fairly ‘bare minimum’ scenegraph representation. (Just to repeat above, I have no plans to implement any such AW entity - this is just a hypothetical example using real world object representations)

Heirachical Entity (VastPark, Melanies Proposal, etc) - In this proposal, the same object consists of multiple independent parts. Each part has a collection of parents and children - however to Scene they are all independent seperate objects.

Each presents a seperate physics shell, each presents seperate property name and ID descriptions - however in special cases such as position or rotation, updating one reflects an update on the entire set simultaneously (or at least any descendants).

Handling the new objects internally

One of the largest problems of doing this (or any change) is that SceneObjectGroup is currently referenced in a very large number of places, making changes to it is likely going to result in a large number of structural changes needing to be done.

As an example of one of those changes - the following is a proposal on how to handle a single event in IClientAPI - OnNewEntity. The following represents the path that two independent IClientAPI implementations would follow in processing the same path.

The goal of this structure is to allow each client the opportunity to attempt to parse foreign object formats - if LLClientView understands XYZEntity enough to write a converter, then it can do so and send the converted result onto the Linden Viewer end user.

Likewise, if XYZClient understands Linden entities, then it can in turn write a converter to it’s internal packet representation and send the same object to it’s viewer.

In practice such converters will not be particularly easy to write - most Virtual Worlds use meshes in a variety of formats, so such converters may need to convert texture formats, mesh formats, etc. For LLClientView converters, it may simply be impossible to convert certain outside representations to something the viewer is capable of displaying and simply choose to display a lower detail representation, such as a bounding box of where the object should be.

To follow this process in detail, we’ll examine the LLClientView’s core processes.

In the first step (1), the Scene fires the OnNewEntity event which each client is listening for - as part of the event payload, the new entity is attached. This gets transmitted as a IEntity interface directly into the clientview.

Here the clientview needs to work out what kind of entity it is dealing with, it may do something like “if(IEntity is LLEntity) { … }” and handle appropriately (2).

As the LLClientStack is innately familiar with the structure of LLEntity, it can pretty much directly package it up to packets and prepare to send it to the end user (3).

However when it sees XYZEntity - XYZEntity is known to the ClientView, so it is capable of understanding it and potentially writing a converter (4) to the own internal packet formats. If we assume for a moment that XYZEntity is a AWEntity described above, then it may choose to create a temporary LLEntity which forms just a single box primitive and then package that up to the viewer.

Finally we’ve got something either in packets or close to it that we can quickly and easily send to the viewer (5). They are capable of seeing ’something’ for each Object in the scene, but naturally you need to be on a suitable client to see ever feature that platform supports.

Things unmentioned

One of the things I have left unmentioned is how to handle certain common tasks such as saving and restoring from the database. For the most part the infrastructure remains fairly similar - we can do a check ‘Is LLEntity’ in the DB adapters and follow the current path, or if we dont have one, we can use the IEntity.Serialise() method to get a text string for each entity which can be saved in the DB fairly easily.

In the case of restoring from the database however we need to in addition implement a IEntityFactory which can take a set of data (such as a serialised version) and restore it to an object, these EntityFactories could be installed via a Application or Region module.

I’d like to share some figures generated over the last month since the change:

Between October 5th and October 27th, we have had 21,000 visits to the website with 82,500 pageviews - the average user spent approximately 5 minutes on the site. 50.7% of visits to the site are new visitors. 54.74% of the visitors to the site were using Firefox, and a whopping 14.61% were using Linux (OSX being 8.77%).

The most popular page on the website is the downloads page (suprise suprise), followed by user documentation, the grid list, configuration and build instructions. The top exit pages (where people stop reading or leave) are pretty much in the same order.

In terms of countries - the US has the largest share of visitors accounting for approximately 30% of our visitors, followed by the UK (10%), Germany (9%), France (7%), Japan (5%), Italy (5%), Spain (4%), China (3%), Netherlands (3%) and Australia (2.5%).

Interestingly, only 60% of our visitors come from English speaking countries - meaning we may actually want to start providing better support for foreign languages at some point in the near future.

With that being said - there are a number of cases where you may upload an asset onto a public grid for the purpose of transmitting it between a finite number of trusted regions. In this case, you dont want the grid operator to have full access to your content, nor do you want it transmitted onto untrusted regions.

What this allows you to do, is encrypt assets on upload - anyone can still download the assets, but only regions with the decryption key can access it. This effectively allows you to secure scripts and other content which is not transmitted to viewers - allowing if you tightly manage the decryption keys and combine with a tighter permissions module, to produce something like the way Second Life handles assets - even across a relatively untrusted and “open” grid.

You can install multiple decryption keys on one server - however only a single encryption key can be used at once (for obvious reasons - otherwise which key do you encrypt with when uploading?)

Some notes on what this can and cannot do

• First - this cannot protect assets once they hit the client, once they are on the client, all hands are untied and the content is potentially free. This does however let you limit the number of clients who can access the content on a public grid, by virtue of allowing you to have the asset only on a closed region within the public grid (therefor only a select number of users can see it.)
• Your decryption keys become your content - protect them with your proverbial life. These keys can be duplicated, copied, etc - you should only hand your keys over when you are certain that the person recieving the keys is trustworthy (a contract may be useful here) - you also should change your encryption keys regularly, you just need to rename the file then OpenSim will generate you a new one on startup.
• I would go so far as to say that having one key for every product may not be a bad idea - that way if the key leaks you dont lose everything - just whatever was signed with it.
• If you choose to encrypt your content on upload, then you will need to sure to rename the key to “.deckey” (from “.enckey”) then give that to everyone who you want to be able to decrypt the assets. If you transmit the key - make sure to do so in a secure manner such as SFTP/SCP/PGP, and not send it in the clear.
• Finally, if you lose your key, delete it or similar - you wont be able to unencrypt it (there’s no hardcoded backdoors or anything else), so make a safe backup of your keys somewhere

Final notes - archiver, etc

This is not a magic bullet solution - it has a very specific set of areas where you can benefit (ie if you dont nessecarily trust a grid operator, or want to carve out a ‘protected area’ within a larger grid and still use things like inventory without busting it up ala local assets) - that being said, in certain cases, it’s now possible to be ‘as secure’ as Second Life (which really isnt that secure, but that’s another topic entirely).

It’s also worth noting that anything that downloads assets on the region server, where the region server has a decryption key, will be getting decoded assets - this means the region archiver, etc. will be getting copies of the unencrypted assets - you should treat archives with protected content in them as exactly that (ie dont go sending them around assuming they are secure).

The Inaugral Sinewave Pub Quiz on OSGrid.org

The initial pub quiz (pictured above) was a success, we got a lot of people to show up - many of whom who have never been onto OpenSim or OSGrid before. We’re so happy with the results that we’re going to go ahead and schedule another one - we’re aiming at Sunday, the 19th 26th of October at 9PM GMT (1PM PST) with a Halloween theme. (Sorry, typo! - edit)

The structure of this event was a three part quiz - a picture round, including naming hollywood movies from a still image (some tougher than others), a music round (name the track from a small clip) and finally a ‘google fu’ round with recent history. There were 24 questions in total - our two first place winners getting 19 of them right (and sharing the $500 in prize money).

Q&A was handled by our bot-in-residence Chinzy Quizmaster running the Sinewave Quizbot code, some suggestions for improvements we’ve added to the development roadmap.

We hope to see everyone who participated at the next one - we had a lot of fun running it and want to make this a regular occurance.

As Promised - The Technical Writeup

Technically the Pub Quiz was overall a success - we got a lot of interesting data out of the test (and a 17mb log file), including the fact that OpenSim seems to scale pretty damn well under a tightly controlled environment. We also managed to isolate and fix three critical bugs with OpenSim which have been contributed back to OpenSim already. In addition we have some information about how OpenSim is handling packets internally which I’ll be interpreting this week to try improve general performance with.

We also learnt some other interesting things about running these kinds of profiled events in future which might be useful to other people

• JetBrain’s dotTrace profiler doesn’t work on OpenSim very well - infact the chances of getting a  “completely random MS Visual C Runtime error” while under their profiler goes up about infinity% (ie, from zero to once every minute). We’re going to try another profiler next time around. A slight shame since we wanted to do a memory profile next time vs re-doing the performance one. That being said, if anything’s going to kill a profiler - we’re it, the Mono profilers dont even start when profiling OpenSim.
• For the most part OpenSim seems to behave pretty well these days, however we do need to get some kind of mechanism inplace to handle when things do occasionally crash to somehow get users into another backup region. EventQueueGet makes this now rather difficult, but it might be possible to do still somehow.
• We’ve still got “Grey Avatar Syndrome” showing up on a number of avatars - however we think these are being caused by simply not having an avatar equipped, or having an avatar that was built with local assets enabled. We definetely need to work on providing a nice default avatar in these cases as the simulator should be able to tell the avatar is using a inaccessible asset.
• Windows 2003 still performs significantly better than Linux/Mono it seems. Our servers didnt hit above 5% CPU usage for the entire event, except during one stack heap (which was fixed). Memory use fluctuated a little bit, but for the most part was sitting comfortably around 230mb of RAM plus a little bit of page.

The short

It’s on OSGrid.org, in the SineWave Region - 5PM GMT / 12PM EST / 9AM PST, Friday the 10th of October (this friday!). Total runtime is expected to be fourty minutes or so. You should register your avatar in advance on this page.

The rest

You should try test logging into SineWave sometime before the event, as we’ll be trying to start promptly. There’ll be other prizes including some hosting from DeepThink and maybe a little more. Performance will be a little slower than usual since the region will be operating under a performance profiler, but should still be acceptable.

As usual, we’ll publish the profiler results to help other developers - if you want to bring friends, feel free as the more avatars logged in, the better the quality of the results we get.

FAQ

Why are you running this, $500 is a lot to give away randomly? We’re doing this as a load test on OpenSim - we’re looking to get about 100 avatars or so and see where OpenSim stresses so we can optimise and fix those areas.

I need to get onto OSGrid - how do I connect? We recommend you grab the Hippo Viewer, it’s free and will connect by default to OSGrid (although it has support for any modern opensim grid)

It should go without saying that a single developer can only achieve X number of features/fixes/improvements in Y time (and not every value of X is equal), but the moment you substitute “X” with specific feature names, it suddenly becomes urgent priority for everyone to stop work on it and get that done, to hell with everything else - although we want that too … and a pony.

The facts of life

The reality is - we’ve got a finite number amount of time, a finite number of developers, and a not-quite-so-finite list of features and improvements we have to spend time on, this means we prioritise stuff. We say “We think stability is a prerequisite before you go about implementing an example micropayments system.” - and with good cause, if the system didnt have that prerequisite stability, why the hell would you trust it to handle important or sensitive information?

This is not to say some of us havnt devoted time to thinking about it, it’s just that we each have our own ideas about what we think is important, and unless you are actively assisting in some capacity (food, booze, code, testing, etc), your personal wish list probably isn’t going to get any attention.

It’s harsh - but there it is. At the end of the day, each developer has a finite amount of time to work on projects, and when they are working on things - there is a strong chance that a specific goal is in mind and needed. If you want to change that goal, you either must have a convincing reason that that person is interested in and agrees with, or you need to provide an incentive to compensate for time that would otherwise be spent elsewhere. It’s also quite possible to just get in there, and do it yourself then submit those changes back.

Backseat Driving

There’s a lot of developers working on the OpenSim project - and each of them has their own ideas, goals and projects. Some of them are working on commercial projects that rely on OpenSim - and hence have some very specific feature and stability requirements that they work on. Others have more free reign by virtue of doing this in their spare time. There is a common misconception that the OpenSim team has an agenda - there’s somewhere around 200 developers on the project which means there’s 200 sets of agenda’s.

Right now, my personal agenda (which by proxy does carry a little across to what the DeepThink developers are working on) looks something like this:

• Abstract login and client initialisation to a more generalised interface to allow third party login and authentication routines to be fitted more easily as loadable DLLs.
• Find where we have remaining hard-coded references to LLClientView bits and bobs, and recode them in a more vendor neutral manner.
• Have a look at some of the terrain control issues reported on the mailing list recently.

It’s a pretty short list - this list gets revised, updated and changed pretty regularly based on what I need to do at the very moment, it’s the same for a lot of the other central developers - they are built on a task-by-task basis.

So - if you have a feature you really want to see happen, that you really think is important we tackle and address, your options include:

• Do it yourself - the code is there and we dont bite when it comes to new contributions. (Just as long as the code matches our other guidelines about quality, modularity, etc.)
• Convince someone to do it for you - this it the hardest of the options since we’re already very busy as a group, but it’s certainly possible. Make a convincing argument - it helps if you can research it and break it down into specific tasks. (”Improve stability” is not a task - “Fix crashes when/while XYZ happens” is.)
• Hire someone to do it for you - it’s an option on the table too. There’s a lot of developers familiar with the codebase now, lots of them are looking for beer money and can implement your pet project or ideas for a fee.

So in conclusion - if you have something you really think is important, really want to see - think it through, ask yourself “Is this more important than what people are working on already”, “Is this something that OpenSim is ready to support”, “Is this important enough that I am willing to work to see it done?”, and finally “If no-one thinks it’s that important, ready or <insert reason here>, am I willing to pay to see it happen?”. Because at the end of the day, features take time, and time is a non-renewable resource - people like to see it invested wisely.

This year at the Virtual Worlds Expo in LA, several of the OpenSim and related developers (including RealXtend and others) decided to sponsor a booth and attend as a large contingent. We’ve been exhibiting, explaining and showing OpenSim to hundreds of managers, developers and users. What most of us did not expect was that we’d be coming home with the VW08 Overall Innovation Award.

It’s rather nice to poke our head up above the water and see that there is some interest in what we are doing, and the recognition doesnt hurt. We’ll post some more on this once the conference is over and I have a bit of time to collate the photos and feedback we’ve gotten.

After long delay, the Screenshot Competition winners

Big thanks to everyone who contributed screenshots for us to use for this event - we used images from the following people/groups in our promotional materials, we had so many pictures to choose from and only a limited amount of space to use (Over 100 screenshots were submitted)

Images we used were from…

RealXtend - Ludocraft and Adminotech - www.realxtend.org
Bin Chen and Tiantian Wang - SecondCampus.net.cn
Myself / Deepthink - www.deepthink.com.au
Warin Cascabel - Escapon on OSGrid.org
United Grid - www.unitedgrid.com

Prizes and everyone else…

You will be able to download the PDFs of the banners and printed materials we made for the booth shortly. Everyone who contributed (not just the winners!) and wants to take advantage of our offer for 6 months free hosting on osgrid.org, please contact me and I’ll get you setup.