Also on the blog now:
http://realxtend.blogspot.com/2010/11/name-file-extension.html

2010/11/25 Toni Alatalo <t...@playsign.net>:
> 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

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

Reply via email to