[X3D-Public] file bundling > web3dx

doug sanden highaspirations at hotmail.com
Mon Jun 9 06:17:18 PDT 2014


Here's another idea for a file bundling strategy:
- file extension: .web3dx
- MIME/Content Type: model/web3d+zip
- .zip compatible with opensource minizip if there's a difference
- in the root, put a web3d.manifest (or .man or manifest.txt)
- in the manifest, name the main scene, which can be in any current legacy web3d format:
<mainscene path="/models/funscene.wrl"/)
To prevent over-writing same-named files that had a different path, a (optional?) lookup table can be put in the manifest:
<urlmap from="http://.../myscenefile.x3d" to="/scenes/myscenefile_A.x3d" /)

- for the content files, put a set of standard named subfolders for different types of content:
/scenes - put all web3d scene file types in here
/images - put all images here
/..


Then native browser developers would set a flag for reading web3dx and either
a) automatically flatten the original url to the standard subfolders (prone to overwriting), or
b) use the manifest lookup table with a check to make sure paths don't go outside the unzip sandbox.

-Doug

more...

I worked with a different bundling strategy before - .x3z which mimics googleEarth's .kmz strategy: name your main scene doc.x3d and put in the root of the .zip folder.
www.cloudvr.net/x3z.html - implements server-size url grooming and zipping via nodejs scritping
freewrl browser implements client-side .x3z reading via opensource minizip.

But web3d supports several scene formats, including legacy, so doc.x3d is a bit too restrictive. And grooming the urls in scene files to new relative paths can be tedious and error prone, and same-named files from different paths over-written. The manifest fixes those issues.
A cleanup strategy is needed for when the browser is interrupted/killed/bombs before cleaning up the unzipped files, for example unzip to a temp folder that will eventually be garbage collected.

 		 	   		  


More information about the X3D-Public mailing list