[sldev] Automatically backing up scripts locally.

[Argent Stonecutter]

On 2007-12-21, at 10:02, Dzonatas wrote:
> I am also concerned about the permissive properties that affect the  
> relationships.

I'm talking about backing up things I'm creating as I'm creating  
them. I'm not talking about backing up things that I do not have  
permissions for: if I upload an image, or edit a script, or create a  
prim, I have full permissions to do so. If I don't have permissions,  
I won't be able to back it up. Whether the backup format is COLLADA  
or LLXML is irrelevant: COLLADA does not enforce permissions, it  
merely documents them.

Also, you keep going on about my ideal scheme.

I don't have an "ideal scheme". When I wrote my ideal scheme would be  
"something like" the example I gave, that's all it was, an example of  
what I would like to do if I was doing it.

I have a set of requirements. The first two are

1. Each asset is stored in a separate file or directory.
    * This allows assets to be accessed directly by any application
    * Saving one asset can not corrupt another
    * Saving one asset is efficient
2. Open-format components of assets are stored in open formats,  
preferably those supported by SL.
    * This allows assets to be edited by any application
    * This means that uploads are automatic, and can be done directly  
from the SL application.
3. The directory structure describes the in-world relationships  
between assets.
    * This makes it easy to locate assets.
    * This maintains the relationship between the backup and the in- 
world assets.
4. Asset contents are not duplicated in the directory hierarchy.
5. References to assets are unambiguous.
    * These last two are desirable for efficiency and consistency.

The example scheme satisfies these requirements:

* Atomic assets are stored as text files, PNG or TGA images, FLAC or  
WAV audio files, BVH animations, and so on.
* Combined assets are stored as directories, containing XML  
parameters and properties and symlinks to referenced assets.
* Assets rezzed in-world are stored under the region.
* Assets in inventory are stored under the directory tree of the  
inventory.

This is an example scheme. There are other possible schemes. There is  
nothing in this scheme that requires you to use COLLADA formats, nor  
does it prevent you from using COLLADA formats, or using both. The  
use of standard file formats is explicitly supported by COLLADA:  
consider the example image file in the spec:

<library_images>
   <image name="WoodFloor">
     <init_from>Textures/WoodFloor-01.png</init_from>
   </image>
</library_images>

So consider a simple one-prim object:

ObjectName
   Properties.xml
   ImageName.png
   Scriptname.txt


Properties.xml could look like this:

   <?xml version="1.0" encoding="utf-8" standalone="yes"?>
   <creator UUID="MY_UUID">Argent Stonecutter</creator>
   <parameters>
     <prim_type type="cube" .../>
     <prim_texture face="0" texture="ImageName.png" .../>
     ...
   </parameters>

Or it could look like this:

   <COLLADA>
     <asset>
       <creator>Argent Stonecutter</creator>
       <extra>
         <technique profile="ll-xml" ...>
           <creator UUID="MY_UUID">Argent Stonecutter</creator>
         </technique>
       </extra>
     </asset>
     <extra>
       <technique profile="ll-xml" ...>
         <parameters>
           <prim_type type="cube" .../>
           <prim_texture face="0" texture="ImageName.png" .../>
             ...
         </parameters>
       </technique>
     </extra>
     <library_images>
       <image name="ImageName" id=UUID>
         <init_from>ImageName.png</init_from>
       </image>
     </library_images>
     <library_nodes>
       <node name="ObjectName" id="UUID">
         ...COLLADA description...
       </node>
     </library_nodes>
   </COLLADA>

The same data, the same files, using COLLADA or not using COLLADA is  
completely orthogonal to anything in the example layout.