A little bit more on OAR May 1, 2009Posted by justincc in oars, opensim, virtual-environments, virtual-worlds.
Hello there. I originally wrote about Opensim ARchives (OARs) back in October last year. To recap, OARs are a way of saving an entire OpenSim region to a single file, which can then be loaded on another region in the same grid or on another grid entirely.
Since then, OARs have become quite a popular way to backup and transfer regions in an OpenSim installation. They have also begun to see some use in distributing content to other people.
So I thought that I’d take this opportunity today just to address some miscellaneous topics about OARs and give a short overview of what’s coming up next.
Standardizing on a .oar file extension
When I originally wrote the OAR code, I made the ‘default’ file name scene.oar.tar.gz (this is the filename used if one hasn’t been supplied in the load oar and save oar commands). I originally chose this because OAR files are tar.gz files with a particular layout, much like Java ARchive (.jar) files are zipped directories with a particular layout.
However, though this is convenient from a command line auto-complete point of view, I think that it just proves too confusing in other contexts. So from OpenSim r9346 (which will be present in the next OpenSim release), the default filename is region.oar (scene has also been changed to region since region is the better terminology). I’m also recommending that OAR files in generally just end with the extension .oar, much like JARs end just with .jar rather than .jar.zip.
No existing OAR names need to change – indeed one could happily continue to load and save files ending in .tar.gz as before. However, I think that just using .oar will make things simpler to understand, especially as most people never need to unpack the OAR file and fiddle with the contents directly.
One recent use of OARs, as mentioned in the introduction, is to transfer content to other people. A couple of websites have even sprung up to facilitate this, such as Rich White’s OpenSimWorlds, RegionWare and rexxed, though actually available OARs are fairly thin on the ground right now (I’d be very interested to hear about other such sites).
I think this is a very interesting development, though I also think there are at least three issues with using the format in this way.
- OARs are an early stage mongrel format. Although the OAR packaging format is documented (albeit minimally), some of the pre-existing components that it uses, such as object serializations, are undocumented. There are the stirrings of a more fixed and better described format in this area (thanks to John Hurliman of libopenmetaverse), but other aspects of OAR are still subject to change.Personally, I aim to always keep OAR loading backward compatible and I don’t see any reason why this shouldn’t remain the case, but this is not an absolute guarantee.
- UUID intercept. Currently, the Universally Unique IDentifiers (UUIDs) used by assets when an OAR is saved are reused when the OAR is loaded. In most situations this is a good thing – if an asset already exists we don’t want to create an identical copy which bloats the asset database. However, it also makes it possible to hijack the UUIDs known to be used by an OAR file by uploading a different asset with an identical UUID first (whether by OAR loading or other mechanisms).This isn’t much of a problem on closed grids where one entity controls all the region servers. It’s more of a potential issue on open grids where there are many different region server operators. There are some interesting possible solutions to this problem but for now it remains an issue.
- Creator information is not retained on inter-grid transfers. If one is saving and loading OARs on a single grid, creator information is always retained. However, if an OAR is transferred to a completely different grid, creator information as shown in the Linden Lab Second Life client is not retained – in which case the label defaults to whoever uploaded the OAR. For an OAR that is being used to transfer content, one workaround is to place credit information in a notecard or in some other visible manor on the region itself. However, this is far from ideal – it should really appear in the GUI where people expect it to appear.I’ve found that this is actually a very hard problem to solve. The simple solution of copying profiles into OARs and restoring them on a load doesn’t work well for lots of reasons. However, there are other approaches which I’m currently exploring in Inventory ARchive work. If this proves reasonably successful it will be back ported to OARs.
Since the OAR format was released, it has changed relatively little (I actually view this as a good thing :). Persistence of region settings has been added. Persistence of parcel information is still missing, as is saving of multiple regions into a single OAR. The former problem is really just a case of slogging through and writing/reading the appropriate parcel information. The multiple region issue is more complicated since one has to start answering questions such as what should happen if the Tetris block of saved region archives from the source region simulator doesn’t fit in the region layout of the target simulator. Patches to help address these issues and others are always welcome 🙂
However, what I’m actively working on now, as mentioned above, are Inventory ARchives (IARs). These are the equivalent of OARs, but for user inventory instead of regions. As with OARs, the necessary commands to use them are not natively accessible from the virtual world viewer. IARs are not intended as a general Second Life client side content transfer mechanism in the same spirit as Second Inventory. Rather, like OARs, they’re intended to be more usable by people running their own standalones or grids.
Work on IARs is ongoing but still some way from a first experimental release,and it’s something that will remain labelled experimental for quite some time.