Hi,

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/doxygen/tundradocumentfiles.html . I think we 
basically just need to write a little more usage docs to at least point to 
where the example scenes are and make an installer. 

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.

~Toni

-- 
http://groups.google.com/group/realxtend
http://www.realxtend.org

Reply via email to