[sldev] Automatically backing up scripts locally.

[Dzonatas]

Argent Stonecutter wrote:
> On 2007-12-20, at 20:31, Dzonatas wrote:
>> Argent Stonecutter wrote:
>>> On 2007-12-20, at 18:18, Dzonatas wrote:
>>>> Argent Stonecutter wrote:
>>>>> In addition, the relationship between the backed-up assets and 
>>>>> in-world object is out of scope of COLLADA.
>>>>
>
>>>> It probably appears out of scope because the published 
>>>> implementation of COLLADA uses a more standalone-ish server.
>>>
>
>>> I'm going by the specification, not any implementation.
>>
>
>> There is some confusion here then. How do you see that there is a 
>> difference between the two assets you stated?
>
> What do you mean? I'm talking about the relationship between them, not 
> the differences between them.
>

Understood.

I am also concerned about the permissive properties that affect the 
relationships. To that, it would have to stay within scope of something 
like COLLADA if not COLLADA itself to respect those properties. The 
filters have to abide by the such properties, for example. In my current 
view of this, instead of a hack to the viewer itself to save scripts, 
any program can query the filter to dump its data. The filter in that 
sense acts as a database cursor.

The process I'm seeing is that one would write their script. A local 
cache of the asset is updated with the script. An event is triggered to 
create a pending request to update the primary database (i.e. in-world). 
Another event can be triggered to run the filter and dump data that is 
allowed to be seen by such query and properties.

Just to enable the ability to save scripts can be done out-of-scope of 
COLLADA. That is fine because we know the viewer now gets forced to 
respect the properties of scripts. For example, the sim doesn't send the 
text of the script.

Going beyond that, there are various properties involved. If we locally 
cache an asset for backup purposes or automation, there are 
relationships in the asset that need to be respected. For example, an 
object that has two scripts but one script has restricted permissions. 
Without any specific implementation, lets say anyone can locally cache 
the asset with all the scripts, restricted and publicly viewable kinds, 
but only one script can be seen. We don't want to allow a complete 
backup (or dump) of the asset because that could look malicious for lack 
of respect about permissive properties such that being able to exploit 
all scripts -- even unintentionally.

Your ideal scheme is not a bad idea. I feel, however, the effort is 
better spent on either the hack to just save viewable scripts (and it is 
a hack) or on efforts to bring COLLADA more in scope. With the ideal 
filter on COLLADA, your ideal scheme is still possible but some 
relations may be restricted.

-- 
Power to Change the Void