For end users, visually, Islands are linked to Space's representation form. But it does not mean that Island = Space.
Island could contain the unlimited amount of Spaces, like other objects as Meshes, Textures forms, Sounds etc. (instances of TObject/TFrame and not only).
That means, that there are could be different strategies of defining complex nesting structures of interlinked Croquet 'worlds'.
Some of them are:1. The first scenario is the creating of one Island, where all Spaces will be added just to it. You will not be able to save(serialize) any concrete Space for later reuse or deployment (in current Cobalt/Croquet SDK for now), but just when exporting the whole Island to c3d file (containing all Spaces). To restore working Spaces is simple, as loading one c3d file.
2. The second scenario is the creating Islands as much as needed Spaces, that every concrete Space could be saved(serialize) inside corresponding Island in c3d file. But to restore the working Spaces you will need to load/connect all Islands at the same time (if you need all living Spaces). For that reason I have started implementing the MultiIslandReaderWriter, that you could try from (http://croquet-src-01.oit.duke
The simple multiIsland file is just a XML text file, which contains the names of Islands to be restored (from cache directory for now). File does not contain the structure of how Islands are interlinked with each other (aka Portals), as this information is stored directly in c3d files of every island separately.
The "saving" in multi-island format, could have a meaning like "multi-bookmarking" in one click. Links to the islands in the saved file could point to the "on-line" islands (aka Postcards) also (in near future), along with pointing to the c3d cached ones or web resources.
So, that there will be all choices from deploying everything to the desktop to just bookmarking, with or without online connection to p2p Croquet network.
