| |
|
|
- Introducing The New Software Interoperability Layer 8
- The DartBoard – layer 7 native device applications which exposes device capabilities to others
- The Dart applications – smarter, self managing-applications
- The Patent Pending Technologies based on how humans work together
- SocialTeaming – the most common denominator
- SocialSecurity – easily building relationships of trust during use
- SocialSynchronization – code that manages Sync distributed with
content
- Evolution – New devices and Darts work instantly with old
- Adaptation – One binary runs well on wide range of devices
- Additional Info – Deep dive Technical FAQ & Security WhitePaper
There were several tough problems that had to be solved in our quest to make devices work together instantly out of the box with no hassles.
First we chose to eliminate all the administrative tasks by making the software applications smart enough to handle all the administrative tasks themselves. The result was a new type of applications which we call, “Darts.”
Darts automatically:
- Find other devices over whatever communications protocols are available.
- Figure out which devices have the content, communications, computation or playback capabilities needed by the application.
- Form these devices into teams
- Get security permissions from the device owners for the code and data to spread and run in an effective, yet hassle-free manner
- Spead its code and data as needed across the team of devices
- Adapt the user interfaces across a wide variety of device displays and controls.
- Coordinate the activities of the teamed devices
In order to carry out all the above, the devices themselves must expose their communications, content and capabilities so the Darts can determine which devices to use. The devices must also provide a common execution environment so the Dart application’s code will run on all the devices once spread, no matter what CPU the device uses. Exposure and common execution are provided by a new software layer, called the “DartBoard.”
The DartBoard is a thin native device application generally ported by device manufacturers and shipped with the device itself. On open platforms, like PCs, Macs, Windows Mobile and Symbian mobile phones, the DartBoard can be installed by the user. The DartBoard is essentially a software emulated microprocessor with the usual test and branch instructions, but which also contains advanced security, exposure, graphics and new types of interoperability instructions developed and patented by DARTDevices.
The DartBoard is software provided by DARTDevices that must be ported to each device. Doing a good porting job requires exposing detailed information on all the protocols, controls, storage options, screens and media playback capabilities. This information is used by the Dart applications to determine which remote devices to spread to and make use of as part of the team best suited to carry out the intent of the application. Detailed information on the screen and controls is also used by the Dart application to adapt its UIs and tasks to run well across a wide range of devices. Adaptation based on the capabilities exposed by the DartBoard is described in a later section.
An important unique feature of the DartBoard is that it can expose any APIs or native hardware or software on a device in a way that makes these discoverable and usable by other devices without any requirement for standardization. This means that an entirely new type of consumer electronics devices can be produced by manufacturers, without the need for any new standards, which will work instantly out of the box with all consumers’ existing and future DARTDevices (devices that have a DartBoard.)
Every Dart application installed on a device by a manufacturer or user enables that device for discovery and use by all future Darts and DARTDevices. This is because the DartBoard gets installed as part of each Dart.
If you’ve read this far you know that Darts are much smarter than your average app.
Darts are not native platform applications like the DartBoard. In fact these are not even conventional software applications; they are much more sophisticated than conventional software applications. Darts are physically a database of code, data and content elements along with other parts that know how to put the elements together to form Renditions, or other executable proper subsets of the Darts. Darts are written in C++, but they must be compiled using the C++ DartCompiler which generates DartCode conforming to the instruction set emulated by the DartBoard. So the DartBoard provides a consistent base instruction set for general purpose DartCode to use. But as mentioned, there are also a host of interoperability instructions a Dart can call and the compiler takes what look like C function calls and translates them into the supported interoperability instructions, such as the Profile Instructions used to discover the characteristics of the devices and what optional or extended APIs exist for the Darts to use. The code and required access rights sections of each Dart are signed so that they cannot be tampered with
So that is how the same binary applications can run on all DARTDevices, because the DartBoard emulates a common instruction set and executes the same binary application code. And this is how we maintain backwards compatibility, by implementing the old instructions and APIs that are needed to support existing applications. And this is how Dart or ISVs can add APIs and new functionality on new devices, by adding your own new instructions to the DartBoard that is ported to the device, but also implementing the old instructions as well. The evolution of the Dart ecosystem is described in greater detail below.
When we set out to solve the tough device interoperability problems, we used a model that is known to work well – people. People are very good at forming ad-hoc teams, teaching each other tasks, figuring out who to trust with what and working together to solve problems. Three patent pending methods based on how humans socialize are used by DARTDevices’ technology to allow devices to socialize better.
Conventional software uses either client/server or peer-to-peer models to cooperate. Dart introduces a new model called, “SocialTeaming.” With SocialTeaming, there is no master as in client/server, and peer applications do not have to be pre-installed on all the devices like conventional peer-to-peer.
SocialTeaming allows a single application binary running on one device to find, inspect, form teams, distribute parts of its code and data and then coordinate the activities on all the teams’ devices to carry out its task.
When a SocialTeaming group is formed, containing multiple friendly devices that have accepted the connection, we call this an “Entourage” of DARTDevices. The Entourage is the group of familiar, friendly, and approved devices around you that share privileged access to each other. Your Entourage will be different from mine, even though we might share some common members.
More specifically, suppose the user directs the DartPictures application running on his Nokia N95 phone to display a slideshow on another device. The Dart will then send a procedure part of itself to run on every DARTDevice it can find over all its protocols, e.g. Bluetooth and Wi-Fi. The procedure is then sent to run on every reachable DARTDevice. When it runs it calls into the DartPlayer to find out if it has a screen, CPU and memory suitable for showing the pictures. If so, it sends back the name of the device which shows up on the N95’s list of available devices (the devices in your “Entourage”). All suitable devices will show up on the user’s phone. When the user selects a device, part of the application is sent to run on that device based on the actual device characteristics. Darts are like multi-threaded applications, except the different threads can be distributed to run on other devices as determined by the procedures that precede them being sent. So a Dart can send procedures to find the device with the best screen and send the display thread to run on that device, while finding a device with the fastest CPU to run the algorithm, while also sending the right thread to run on the device that has the fastest communications link to the Internet. Dart applications can intelligently mix and match to exploit the best features of all its connected devices in any combination. Once the threads are distributed, all the activities are carried out by the Dart by posting and processing Events. Events carry requests for an action, content or status. All devices in the team are guaranteed by the cooperating DartPlayers to receive all the Events generated on all the devices in the same order. This is like a team of people all using email to send data and status and request actions to get a task done.
If you’re still reading, but we haven’t described it in a way that makes sense to you yet, here’s a human analogy: Let's say that I know how to play a game, like Sudoku, but you don’t know the game. You can ask me to play, and then I would talk to you in a language (say, English) we both understand and teach you how to play. Similarly, among devices, the DartInstructionSet as implemented in the DartBoard provides the common language and communications paths so that one device can ask another about the apps it knows and ask to be taught to play. Thus, Darts automatically teach each other how to perform applications, in real time as needed, without the need for humans to install or configure new software.
If reading this makes you concerned about a possible malicious aspect of apps that are capable of spreading themselves, be sure to read the next section on security.
If you read the previous section on SocialTeaming, you may be concerned that Darts appear to spread code and data much like computer viruses. Be assured that there is a security model that only allows the code to spread and operate with permission of the owners of the devices. Only those devices that have been admitted to your Entourage enjoy privileged access to your other devices.
Setting up the security for networks (for example, Bluetooth Pairing and Wi-Fi WEP/WPA keys) across all your devices is one of the biggest hassles that Darts are designed to eliminate. Our solution is based on how people learn to trust or not trust one-another. We establish trust with others based on our relationships and experience in working with people. Let’s say a user takes pictures with DartPictures on his Blackjack phone at a friend’s party and wants to control a slideshow of the pictures on his friend’s Mac. If the Mac contains any Dart applications then it is also running a DartBoard and can be found by the DartPictures Dart running on the Blackjack over Bluetooth. If the user selects the friend’s Mac the SlideShowing thread and pictures will be sent to run on the Mac, but if the Mac has never worked with the Blackjack before, it must first get permission before it will run. The DartBoard running on your friend’s Mac will ask you friend what her relationship is with you, the owner of the Blackjack (it gets your device and your name automatically from your profile). You friend can select the “Friend” option which will then allow the SlideShow display portion of DartPictures to run on the Mac.
The Mac will remember that your device is in its Entourage as a friend, and so the next day when you extend the DartBattleBoats game from your Blackjack to your friend’s Mac, no questions will be asked. With SocialSecurity, devices quickly learn their relationships and set access rights accordingly. Your Friend’s Mac will allow you to run applications like DartPictures and DartBattleBoats because they only need to access the screen and controls and public information of the Mac.
Applications that require the ability to access private content or fee based communications must ask for more permissions before they will run. Security goes well beyond the SocialSecurity model and includes sandboxing to prevent the spread of viruses, signing to prevent tampering with the code and required access rights, and automatically encrypted communications sessions to prevent eavesdropping. A deeper dive on security is presented in the DartSecurity Whitepaper, available to partners on request.
How lame is it that your iPod only sinks its play lists with one computer? Shouldn’t your contacts automatically link across your phone, on line email, and Outlook whenever you make a change to any of them? Shouldn’t all the devices in your personal Entourage be able to take full advantage of each others’ resources?
Humans are able to synchronize information about the world across billions of people without requiring any specific master bastion of information: We all learn about major earthquakes, the hottest thing at a trade show, sports scores along with the latest gossip about Britney Spears through almost random interactions with others and news sources. Darts can also synchronize information across any number of devices in any order with no ‘master’, using the method we call SocialSynchronization.
SocialSynchronization is used by applications which need to synchronize content or operations across many connected or intermittently connected devices. Individual Darts spread themselves, along with a statistically unique SynchronizationId, from device to device under the user’s control. The Dart registers the unique ID and saves itself as it is spread. Then whenever any DARTDevice sets up communications for any reason, the DartBoard automatically compares the registered Synchronization ID lists. If the two devices have the same ID then they need to synchronize. The DartBoard on the more capable device will automatically start the Dart that registered the ID, the Dart will then spread itself to the other device and do whatever it is programmed to do to carry out the synchronization of content or tasks. Note that this mechanism is very general because the code of the application is synchronized along with the content.
So, if we’ve explained this well, you now understand how a Dart running on one device can spread itself and make use of devices it initially knows nothing about. Now we’ll look at how an existing device can work with future devices it knows nothing about.
The DartRemote Dart is generally put onto any device that has a UI as part of any Dart app installation (which of course includes the base DartBoard installation) if needed. When run, this Dart sends out a procedure to all the DARTDevices with which it can communicate, then executes the interoperability instructions that enumerate the names and descriptions of all the Darts, including Dart control panels that are on the target devices. These name/description lists are sent back to the originating device and show up on a list put up by the DartRemote Dart which sent out the procedures and collected the responses. Now we have descriptions of devices that the originating device knew nothing about. When we select one of the control panels, an event is sent to the device containing the control panel that makes the control panel Dart itself start running on the device on which it is stored. When the control panel runs it uses the open communications channel that the DartRemote application opened and sends back part of itself which can implement any UI the target device wants to offer up. Thus the DartRemote was used to find other devices and fetch the descriptions of what they can do (the Darts that carry out the operations on the target device are on the target device). Then any selected Dart will be triggered to start-up on its target device and spread the UI part of the application to displace the DartRemote application that used to find and start it. For the user all she has to do is start the DartRemote on her phone (from a convenient Menu choice in the UI) and she will see all the devices, and the DartControls that she can use to control them. Selecting a control panel will cause its UI to show up on her phone so she can control the device. This works with any Dart application, not just Dart control panels. So in general, any DARTDevice can find any other Darts on any other DARTDevice in its Entourage. Of course exposing Darts and Dart control panels on a device can be turned on and off by the device owner.
Previous attempts at binary portability and interoperability have not lived up to their promises. A good example is Java/Jini. One of the major reasons Jini is no longer even a project at Sun is that existing Java Virtual machines do not supply the detailed information needed for applications to adapt themselves, nor do the applications have the methods needed to adapt easily and broadly. Dart fixes this using three complementary patent pending methods, Profiling, Renditioning, and Creationism:
- Profiling is used to provide to the Dart applications descriptions of the hardware, software and content in great detail and allow new software and hardware to be exposed as needed by any manufacturer without needing to explicitly create new standards or get the cooperation from other application or device manufactures.
- Renditioning is used to adapt coarsely to major classes of devices. When you write a Dart application one of the base objects is the Rendition. This is the starting point for each of the threads that can be sent as a unit to other devices. The inspection procedures that the application sends out can access the Profile information and decide which threads, also called Renditions, to put into which devices. Typically, an application with a UI would have three UI Renditions, one for PCs, one for mobile phones and one for text only devices. Any Dart that prints would likely have a print rendition to be sent along with data to a printer or PC that exposes a printer to carry out the rasterization and printing for the application.
- reationism is used to fine tune the renditions before they are sent based on what the user has asked to do and the characteristics of the target device. DartPicturtes contains a Print rendition that takes a list of pictures, size and format parameters and prints them when it gets run on a selected PC or printer. Before the Print rendition is sent Creationism is used to add the pictures and parameters to the Print rendition. In effect the application can modify or create customized Darts to run on other devices as needed.
Dart technology is the result of five years of heads down design and implementation. It is broad and deep. If you would like more detailed technical information, or are interested in how Dart enhances existing standards like DLNA, you are welcome to request our technical FAQ and Secutity White Paper. Just request it from our Feedback Form.
|
|
 |
|
|
