I think we are really close to being able to release a kind of preview demo of Tundra, i.e. Naali with the server module & executable. One key is that Jukka wrote a nice doc about how to use the document/scene/application files and explanation of what they are, and I changed the public doxygen to use the version from Tundra branch so the page is up at http://www.realxtend.org/
As you can read in the doc, the local server works nicely as a preview / editor thing -- it is not only for people who want to host servers, but also for e.g. modellers, texture artists and scripters to easily see how their things look and work in ReX. The server executable is a normal Naali app, shows the scene using Ogre etc (but you can optionally run it without gfx for server usage). A bit like the local scene preview in Naali now, but much nicer and faster 'cause you don't need a server connection anywhere -- just run Naali standalone to view local files. By clicking a file in your file manager so it starts Naali showing that scene. Besides these own document files in the internal format, you can of course also import dotscene files as well, and there's support for not only Ogre meshes but Collada too etc.
There is one non-technical issue remaining, and I feel a bit stupid to bring it up 'cause is kind of nitpicking, but it is something we should get right the first time so is worth some consideration now. It is the file name extensions that I was asking about in sprint planning as well. We talked about with Antti yesterday but didn't conclude and he suggested posting here to get ideas & feedback, so here we go. Because the issue is non-technical and I'd like to hear user opinions, decided on last minute to post this to users list instead of the -dev list.
Currently, like that doc says, we use 'txml' and 'tbin' for so-called Tundra files. Previously they were just .xml and .bin but the guys added the t* to make them unique for registering to operating system so that opening them directly to the right application works. There is a couple of problems with these names:
1. That entity-component serialization system is not really Tundra specific, is not in the server module and not tied to any protocol. It is implemented in Naali core and was originally and will used with Taiga (to store Naali EC data on opensim, started in last March or so). I've been testing the idea of calling the format the 'realxtend format' instead, and it seems to make sense. Matti K. at least agreed in the meeting. The counterlogic here goes that Tundra is the name for the design, the legacy-free usage of pure EC data for making everything without things hardcoded in e.g. LLUDP / SL assumptions. And that Tundra is a strong nice sounding name! With this logic if there are some day other implementations that support the Tundra way, they also implement the Tundra protocol and the support for Tundra files etc. .. e.g. a modtundra to opensim? This might be confusing though 'cause otherwise Tundra is the name for the server module implementation in Naali. One funny point with the current 'txml' and 'tbin' names is that 'cause Taiga also start withs T, we could say they are both Tundra and Taiga files :)
2. Erno argued that there are also many other XML (and of course binary) files used with Tundra (i.e. Naali), and I think that's a good point. For example the module loading configuration files are xml, in modules/core/*.xml -- those could be called 'tundra xml files' as well. It would be good to say what is in the file in the name, and in one way it is the scene. Jukka's doc also says "a scene file". So Erno was thinking .rts for RealXtend Tundra Scene could be it, which is logical enough but I don't think that sounds too great :o (even though one idea with the generic EC model is to allow making Real-Time Strategy games :)
I was now thinking of these extensions again, but now with better logic:
.rex - RealXtend Entity XML (earlier just thought it's RealExtendXml :p)
.rxb - .rex binary (rxb just sounds like 'rex in a tight binary form', doesn't it?-)
The files are exactly the entities, the whole idea of the formats is to store the entities, either a full scene or just some selected entities. There is nothing else in the files, not for example assets like Collada .dae files can have (dae is 'digital assets exchange'), nor some generic Tundra config stuff .. only the entity-components with their attribute values.
Opinions? Please anyone tell yours, this is for end users, you don't need to be a dev to be a stakeholder .. these are the files you are gonna be using to do work with your stuff!
For folks familiar with OpenSim files, .txml/.rex files are like the files that save-xml2 writes -- have the full scene, with asset references, without assets themselves. To make a bundle with assets like OARs are, you can simply make a zip with e.g. a folder with the assets. I guess we must come up with a name for these zips later too, like OAR is (they are tar gzips). If OpenSim gets the generic EC stuff to core some day, then OAR and tzip/rexzip files may become the same.