 |
Home | Changes | Index | Search | Go
The "Lightweight cell" use case
This use case is meant to provide a user context for how we use a number of Wonderland 0.5 features, including modules, the content repository, and others to let users easily create and share new cell types. The goal of this use case is for a user to create a "singing teapot" in Wonderland. The teapot will appear in-world as a large teapot. When a user clicks the teapot, it will sing a short song, spin around and tip over. The user should be able to build this cell without any code changes to Wonderland, and then be able to easily share what has been built.
The use case
The initial condition is that the user has access to a number of Wonderland worlds, and can move between them using federation. The user has access to create new objects in each of these worlds, but does not have the permission to change any Wonderland code.
The use case is as follows:
- the user models a teapot in sketchup and exports it in .kmz format
- the user records the singing teapot audio
- the user imports the teapot model into Wonderland
- the user clicks on the teapot to open the cell editor
- the user adds an audio capability to the teapot
- the user uploads the audio file in question
- the user writes a script to react to clicks by animating and playing audio
- a second user comes into the world and sees the teapot
- the user decides the artwork isn't quite right, so updates the model in sketchup to add a texture
- the user edits the teapot to change the artwork
- the user is happy with the teapot, and decides to store it in inventory
- the user moves to a different part of the world and instances a new teapot
- the second user tweaks the second teapot script to turn a little later in the song
- the user moves to a different server and instances a new teapot
- the user exports their teapot as a module so it can be shared with others
- a remote system administrator installs the teapot module
- a remote user instantiates the teapot in their world
Below are step-by-step details on each piece of the use case, focused on how they should be implemented in Wonderland. Feel free to add comments/proposals to each section. Please identify yourself in comments:
1. The user models a teapot in sketchup and exports it in .kmz format
There is nothing Wonderland specific in this step. Are there any special constraints on the modeling process?
2. The user records the singing teapot audio
Also nothing Wonderland-specific.
3. The user imports the teapot model into Wonderland
User Experience
In this step, the user uses "Tools->Import" to open the import dialog. This lets them select a model, put it into the world and do some very rough initial positioning and scaling. After the model is in place and the user hits "OK" on the dialog, the model should be visible to all users in Wonderland. It is possible some security will be applied so that other users can't see the model in this initial state (?).
Implementation
Jon's Proposal:
- The client code processes the COLLADA model to make sure all textures are properly relative to the model directory.
- The client then creates a new directory in the user's WebDAV? space for the artwork, and uploads the models and textures to that directory. The user now has a URL to the model file in the WebDAV? repository.
- A new cell creation message is sent instructing the server to create a ModelCell?, with the URL of the artwork in WebDAV?.
- The client receives this message, creates the cell and based on the cell setup downloads the model file.
- As part of model file loading, the texture URLs in the model file are replaced by Wonderland art (wla://) type URLs, specifying the texture locations.
- The wla:// URLs are resolved with the asset manager, which uses a web service to download the checksums for the textures before downloading the texture. * Checksums could be calculated lazily by a separate web service, based on the "last modified" date of the asset in the content repository -- since the server has local access to these files, this should be fairly fast. * Alternatively, checksums could be calculated at upload time by modifying the WebDAV? servlet. Checksums would then be stored directly in WebDAV?.
- At this point, the art is in the world, and anyone coming into the world will see it.
4. The user clicks on the teapot to open the cell editor
User Experience
This will bring up the cell editor dialog, allowing users to add and edit cell capabilities. This is documented: (where?)
5. The user adds an audio capability to the teapot
User Experience
The user selects "audio" from a list of capabilities in the cell editor. This creates a new area for editing audio-specific properties of the cell.
Implementation
Jon's Proposal:
The audio-treatment component is dynamically added to the cell, by sending a message to the server containing the component setup object for the treatment component. At this point, there are no changes to the cell, but new scripting interfaces are now available to the cell.
6. The user uploads the audio file in question
User Experience:
As part of the audio-specific configuration for the cell, the user gets to enter options for what audio files to use in the teapot. The user's task in this dialog is to create a mapping from "script-friendly" names to URLs. A browse button lets the user see the existing audio files available on the server and in their folder on the server. In this case, the teapot song is not available on the server, so the user selects "upload" to put the audio file in their folder on the server. Once the file is uploaded the URL is listed. The user gives this song the name "teapot-song", which can be used later in a script.
Implementation
Jon's Proposal:
- Browsing is done by exploring the system area of the WebDAV? repository for global sounds, and the user's WebDAV? area for person sounds.
- When the user decides to upload their own sound to the server, it is uploaded to their personal area of WebDAV?
- Once the sound is added, a message is sent to the audio-treatment component on the server recording the new mapping from sound name to URL. This value is distributed to the audio-treatment component of anyone who sees this cell.
7. The user writes a script to react to clicks by animating and playing audio
User Experience
Similar to the audio case, the user opens the dialog for the scripting capability of the cell. The user creates a new script, and gives it a name. The script uses the capabilities for audio, events and animation to react to different events. We should get a real sample of how this could look:
// totally made-up script
var teapot = cell.getEntity("teapot-model");
var audio = cell.getComponent("audio-treatment");
var position = cell.getComponent("movement");
teapot.onclick = function(event) {
// animate tipping
startTipping();
// start playing the sound
audio.playTreatment("teapot-song");
}
function startTipping() {
// ?
}
Implementation
Jon's Proposal:
- A script component is dynamically added to the cell
- The script is uploaded to the user's WebDAV? area and a URL is returned
- A message is sent to the script component of the cell to load the new script at the given URL
- When the client receives the message, it downloads the script and executes it on the cell in question
- On a click, a message is sent to the audio-treatment component to start playing the selected audio file
- The server side of the audio-treatment component translates this into a bridge message to play the given URL
- The voice bridge starts playing the treatment from the given URL
- Messages are also sent by the animation system to synchronize the animation playback (?)
8. A second user comes into the world and sees the teapot
Implementation
Jon's Proposal:
- The user receives a cell setup message containing the information about the cell and its components
- The model cell area of the setup message contains the URL of the model to load
- The script component area of the setup message contains the URL of the scripts to load
- The animation component area of the setup message contains information about the current state of animation
- The second user's client creates a new cell based on the downloaded setup information
- The second user's client downloads the model files and textures, first checking its cache based on the model URL and http if-modified-since values. Additionally, textures trigger the downloading and comparison of checksums to determine if they can be shared.
- The second user's client downloads the scripts, first checking its cache based on the script URL and http if-modified-since query
9. The user decides the artwork isn't quite right, so updates the model in sketchup to add a texture
All done out of world.
10. The user edits the teapot to change the artwork
Jon's Proposal 1:
User Experience
The user opens the edit dialog on the cell, and selects the "model files" area. The user then selects the existing teapot model file, and clicks "replace" to upload the new version.
Implementation
- The edit dialog displays the current model information
- Uploading overwrites the original model and textures in WebDAV?
- A message is sent to the server to notify clients that the cell has been modified
- The server sends a model changed message to all clients, which are handled by the model cell
- Both clients model cells check the webdav modified dates for the model and textures that make up the model
- Once it is determined that the textures have changed, the model cell unloads the current artwork and loads in new artwork
- All scripts and other components are reinitialized (?)
Jon's Proposal 2:
User Experience
The user selects "WebDAV URL" in the model's edit window. They then copy-and-paste the resulting URL in the "connect to server" dialog on their system. They can then edit the textures and models directly in the WebDAV? repository from their art tool, and save them normally when they are finished. After they have finished editing, they select "reload" on the cell in the edit window, which causes everyone in view of the cell to update to the new version.
Implementation
- The WebDAV? URL is generated based on the location of the file's models
- WebDAV? editing and usage is handled outside Wonderland
- When the user selects "reload", a message is sent to the server to notify clients that the cell has been modified
- The server sends a model changed message to all clients, which are handled by the model cell
- Both clients model cells check the webdav modified dates for the model and textures that make up the model
- Once it is determined that the textures have changed, the model cell unloads the current artwork and loads in new artwork
- All scripts and other components are reinitialized (?)
11. The user is happy with the teapot, and decides to store it in inventory
User Experience
The user clicks on the teapot cell, and selects "copy to my briefcase". A copy of the teapot now appears in the user's briefcase.
Implementation
Jon's Proposal:
There needs to be a way to "wrap up" a cell and all its associated files. One way to do this would be to create a directory in the user's area of WebDAV? for each cell. For every piece of cell content (scripts, art, etc), either the file would be there, or there would be some type of link showing where the original location of the needed file is. For example, if I create a cell that uses an audio file in the system area of WebDAV?, there should be a link to that file at its system URL. HTTP redirects could be a possible mechanism to make this transparent. The WebDAV? directory should probably be layed out identically to a module with the same content. Given a directory in module format, it should be easy to simply download the entire directory and all its contents to the local disk.
12. the user moves to a different part of the world and instances a new teapot
User Experience
The user clicks on the teapot in their briefcase and selects "deploy". This creates a new copy of the teapot in the current location.
Implementation
Jon's Proposal:
To create the second teapot, the user would upload a copy of the local directory to the server. For components that originated on the same server (for example, assume the .au file is the same in teapot 1 and teapot 2), the user can check the modification date of the local version versus the version currently on the server, and decide whether to upload the data or just create a link.
13. The second user tweaks the second teapot script to turn a little later in the song
User Experience
The second user clicks on the second teapot in the world and selects edit. They edit as above to modify the script.
Implementation
Jon's Proposal:
This is where things start getting difficult. I imagine the second user won't have write access to the first user's data, so the second user will create a copy of the entire module from user 1's WebDAV? area, presumably leaving links back to all the unchanged content. Then the second user will upload the updated script, replacing the link in their copy with a real script. Finally, they would send an update message to everyone telling them where the new source of data for the cell is.
14. The user moves to a different server and instances a new teapot
User Experience
Same experience as creating a second teapot on the same server.
Implementation
Jon's Proposal:
This would work the same as creating a second teapot on the same server, except that all content would be copied since none of it exists already. In addition, federated servers could share a single WebDAV? repository, so potentially the data would already be accessible to the client.
15. The user exports their teapot as a module so it can be shared with others
Implementation
Jon's Proposal:
If the teapot is stored in "module form" on webdav and local dist, this would just be a matter of jarring up the data stored on disk.
16. A remote system administrator installs the teapot module
Implementation
Jon's Proposal:
Teapot is installed as a normal module. Content would be deployed by normal deployers (which may copy data to the WebDAV? or may serve it locally).
17. A remote user instantiates the teapot in their world
Implementation
Jon's Proposal:
Works as above, but content is stored in the system area.
|