Asset API liveupload support.

21 views
Skip to first unread message

Jukka Jylänki

unread,
Feb 23, 2012, 4:13:56 AM2/23/12
to realxt...@googlegroups.com
This commit by Lasse
https://github.com/LudoCraft/Tundra/commit/639bf10dfb32443fdb7c9f7d4b5d142e564a5c49
adds the support of 'live-upload' for Asset API asset storages. This
allows Tundra to automatically re-upload modified assets when they are
edited locally. This enables the following usage scenario:

1. Users A and B are logged to a server.
2. The scene contains a file object.material.
3. User A uses the Tundra built-in material editor, or an external system
file editor to edit the file, which is stored in cache.
4. The storage has live-update and live-upload enabled, so therefore
Tundra picks up the file-changed notification and immediately uploads the
new modified version of the asset to the storage.
5a. If the storage supports, it notifies user B of the changed asset.
5b. If the storage doesn't support notifications, it can relay a
notification message via the Tundra server using the MsgAssetDiscovery &
MsgAssetDeleted messages (in AssetModule).
6. The Tundra client for user B downloads the new asset and displays the
modified material.

The 'live-upload' feature controls the #4 above. The #5a requires support
from the asset storage class itself. Now Tundra HTTP asset storage could
be enhanced with some ajax-based change notifications to provide #5a. The
#5b is implemented autonomously by AssetModule.

Here's a recap of the various asset storage parameters:

- type: Tundra comes with LocalAssetStorage and HttpAssetStorage storages.
Developers can write their own storage types for their own protocols.
- name: A custom identifier for the storage. May contain spaces, but
restrict to ASCII.
- src: The source address for the storage. For LocalAssetStorage, this is
a local filesystem path, e.g. c:\my\storage\. For HttpAssetStorage, this
is a URL path, e.g. http://www.myserver.com/assets/.
- recursive: If true, assets are automatically looked up recursively from
subdirectories without having to explicitly specify the subdirectory.
Configurable for LocalAssetStorage, always false for HttpAssetStorage.
- readonly: Tells Tundra not to ever try to upload assets to this storage.
- liveupdate: If true, Tundra will automatically reload and locally use
the new asset if it changes on disk. Assets that come from the network are
cached to a Tundra asset cache folder - they can be modified there and
liveupdate is still applied.
- liveupload: If true, in addition to locally reloading a modified asset,
the asset is also automatically uploaded to the storage. If liveupload ==
true, then liveupdate must be true and readonly == false for this to work.
- autodiscoverable: If true, the client will query this storage to receive
information of all assets inside that storage (but does not download them
until needed).
- replicated: If true, Tundra server replicates this storage to all Tundra
clients that connect to the server. This allows both server and client
utilize the same asset storages.
- trusted: The contents of this asset storage are trusted, and asset types
that are considered unsafe are allowed to be used (scripts).
- localdir: For HttpAssetStorage only: If the server is running both
Tundra server and the web server on the same system, this allows
specifying an alias path telling Tundra the local folder that corresponds
to the http path.

Using the live-upload feature, we can edit any asset on one system, using
any external editor we like (Blender, Paint, Notepad), and all the other
clients on the server can immediately see the changes happening on their
local systems. Cool!

jj

Reply all
Reply to author
Forward
0 new messages