Update: a subset of the most recent A mini-distribution of QuickSilver Live Objects is available online
Contents:
This tutorial assumes you've installed the following:
After you satisfy these and download the zipped installer, you will need to request from us the decrytpion key.
We will also be interested in a user's guide of the latest version of QSM, available from the QSM project webpage.
This section contains how to run examples. In this tutorial, you will see a lot of screen shots and explanation for examples.
You will see two icons above on your desktop after the installation process. If you double-click the first icon, you will see a folder with live objects. The second icon points the link to a short QuickSilver Live Objects readme installed on your machine.
They look like ordinary files. But each of them is a distributed object based on multicast protocol. So unlike an ordinary file, it can be accessed by multiple users.
The Shared Text Note can be editted by multiple users at the same time.
To run this exampleLet's start a server, "channels_server.liveobject" in a "examples" directory fist, as you see below.
The server will control multicast channels. We could use other multicast systems by simply changing configuration settings.
Now multicasting is working. Let's start a live object, a shared text note, "shared_text_1.liveobject" in the examples folder.
This one is a simple shared text note. It can be edited by multiple users at the same time. In real life, multiple users could open the text notes on different machines.
Let's run another shared text note which shares the same multicast channel with the first shared text note. Here this happens about one second after the user stops typing. So they seem the same text.
As you see, all users see the same text. Whenever one user makes changes, the changes propagate to the others.
Let's start the other shared text note which doesn't share multicast channel.
The first text note which you can see on the screen will stay unchanged. So now I effectively have two multicast channels each containing different data. In a sense, just like the content even ordinary text file resides on the disk, the contents of our short text note reside inside of the communication channel.
As you have seen in the shared text note example, normally live objects have its own multicast channel. In a sense, like the content even ordinary text file resides on the disk, the contents of our short text note reside inside of the communication channel.
The channels are themselves live objects. They can be posted in live folders that we can browse just like we browse ordinary files. As you can see above, we can drag them onto the desktop or send over e-mail.
Now here is an example of live object, a shared desktop. Let's start a server first. Then run a shared desktop.
It is a collection of live objects scattered around on a large two dimensional surface. For instance, we can drag my text note, "shared_text_1.liveobject", drag it onto such a desktop.
Then you may want to type some text into the shared text note. Once you make changes, the changes propagate one second after you stop typing to the others as you see above.
As you see, the note as displayed on the desktop stays in the synch with the shared text note windows. So the same object can be embedded in various places. And no matter where it is embedded, where it is accessed from, it always looks the same.
Let's zoom in and out the desktop by scrolling a mouse wheel on the desktop.
Using this technology, we can create arbitrary mashups. Let's add an image live object, "image_1.liveobject" in the examples folder, to the desktop. Since there is no image on the image live object, you can drag and drop an image file such as bmp, jpg or gif
Let's start another process to display the same desktop.
As you see here, the contents of both desktops stay identical. We can edit the embedded object directly at any time.
Now I am going to embed another desktop inside of this desktop.
So as you see, embedding can be recursive. You can very easily create live documents with complex hierarchical structure.
We have already seen one shared folder in the section of the "Channels Sample". It was a list of multicast channels.
Let's start a server and a shared folder, "shared_folder_1_view.liveobject" in the examples folder.
The server will control multicast channel. The shared folder can store any type of objects.
Like most objects, this folder uses a multicast channel to store its data.
Lets start another process to display the same desktop.
As you see here, the contents of both folders stay identical. We can drag and drop any objects directly into the folder at any time.
Let's start (1) a server, "channels_server.liveobject" (2) a shared folder, "shared_folder_1_view.liveobject" and (3) three dimensional desktop, "window_x.liveobject" in examples folder.
By dragging a shared folder, "shared_folder_1.liveobject" in the examples folder onto the desktop, we can attach the desktop onto the folder.
The desktop does not show you anything for now since there is no live objects in the shared folder. Now desktop provides another view into the folder. It displays all live objects that have three dimensional user interface.
For example, I can drag a 3D map, "map_3d.liveobject" in the examples folder, onto the desktop.
You can notice how the folder gets automatically updated. This is because the folder and the desktop are connected to the same multicast channel.
As you see above, we can navigate the space on the map.
In particular, the map graphics could be rendered based on live data. In order to show that, let's drag and drop three live buildings ("building_00_model.liveobject", "building_01_model.liveobject", "building_01_model.liveobject" in the examples folder) into the shared folder or onto the map.
The color of this building is connected to multicast channel. The channel carries a stream of color values. Right now nobody is multicasting. So let me start a publisher ( "building_00_server_0.liveobject", "building_01_server.liveobject" and "building_02_server.liveobject" in the examples folder ) to multicast a stream of color values.
As you move their ruler, new values of color are calculated and published on the channel. And every object connected to it updates itself.
For example, if the map displayed the status of the rescue mission, the building colors could indicate whether the buildings have been searched or not. The data would be published by the devices carried by firefighters. This plate on the desktop could be in the mission headquarters.
Let's drag and drop more buildings (from "building_03.liveobject" to "building_15.liveobject" in the examples folder) onto the map or the folder .
Now the buildings don't move. So I can add an airplane, "plane_0_model.liveobject", to this mashup by dragging it from a folder. The airplane object is also based on a multicast channel. This channel is a stream of the airplane's coordinates, speed, orientation and space. Now we wouldn't see anything unless somebody was multicasting those coordinates. So I just started a publisher, "plane_0_server_0.liveobject".
Let's zoom in the objects on the map. In real life, such a publisher could be connected to airplane's GPS device.
Although this looks like game, it could be a representation of reality based on a real input. Let's add more airplanes from "plane_1.liveobject" to "plane_9.liveobject". Right now, we have thirty objects here each associated with its own private muticast channel.
As you might expect, if I start another spatial desktop and connect it to the live folder.
We will see the exact same map, the same planes and buildings.
In our architecture, objects can be easily reused. For example, we can take channels with the stream of airplanes' coordinates and connect it to the camera of our spatial desktop. If you aware of real airplanes, you would essentially have a live pilot's view on the area. We can switch between these views easily by grabbing different streams of coordinates and dragging them into our spatial desktop.
Let's start a Live Object Designer, "designer.liveobject" in the examples folder.
The live objects designer shows you how objects are hierarchically constructed out of other objects and how we can easily create new ones by modifying existing ones.
Once we start a live object designer, we can drag and drop the airplane object, "plane_0_model.liveobject" in the examples folder into designer's workspace.
The designer shows an internal structure of the airplane. It is based on a template with two parameters. One is a resource, the texture used in rendering. There is stream of values, stream of coordinates. we could have used any value of stream. Here we are parsing a reference, the subscriber object.
This one takes its values from messages published on a multicast channel. The channel itself is gaining objects. It is a checkpoint of channel. It carries messages but also can transfer a state between its clients. Most objects come from an extensible object library but this channel has mysterious identifier.
In our infrastructure, everything has a well-defined type. Strong typing allows us to catch incompatibilities at the design time.
comming soon...