 | |
In 1984, the Amiga 1000 burst upon the scene of an unsuspecting world. Such was its revolutionary nature that people only had to use one for a few minutes before they experienced an almost religious shiver down through the soul, as if all the confusion and frustration suddenly went away and everything made sense. The Amiga 1000 was revolutionary because it stepped aside from common convention. It took a fresh, unfettered look at the problems of computing, video, and gaming technology. It worked out the problems, the bottlenecks, the issues, and then solved them in a simple, elegant way.
|
| | | | | | |
 | |
Fifteen odd years later, we've flashbacked to 1983 were traditional technologies and approaches dominate. Advances are now mainly through process enhancements: Faster processors, faster graphics cards, more memory, prettier operating systems, more utilities and functions. Innovation has stalled because there is too much investment in the past to allow the future to profit.
Yet the future is there. The volume of digital content is growing exponentially, with the demand for that content not far behind it. Access is becoming ubiquitous, broadband is common. In a few short years, the Internet has gone from being a geek oasis to the place we all go to shop, pay bills, send letters, talk and play. We all want to have our digital kingdoms at our fingertips, available everywhere, at any time, and instantly--and yet we can't. Why? Because what we want doesn't fit into the technology of today.
Computers are expensive. Computers are complicated. Computers are frustrating. They were built to handle batch files stored in rigid hierarchies using big applications. In short, the digital revolution has outgrown its computer nursery. To understand the Amiga solution for tomorrow requires a paradigm shift, the acceptance of a certain set of core truths. Otherwise, people will just end up trying to smash traditional ideas against a new model to no avail.
AmiVerse
Firstly, there is no such thing as a file. All elements are now just digital matter, a stream of zeros and ones. Second, there are no applications. There are just activities that involve producers and consumers of that digital matter. Third, there is no such thing as an operating system. There is merely a set of services produced by service providers and consumed by service requestors. Fourth, these services, producers, consumers and digital matter exist independently of individual physical devices.
Now these four core truths may seem bizarre when measured against traditional computing architectures and models, but that is an indication of how our view of the world has been warped to fit in with traditional computing paradigms. In fact, our photographs aren't files, our apples aren't files, and our life isn't a directory structure. We buy wine from a store, we don't need to have a vineyard, a winery and a bottle producing factory to get that wine.
Humans have spent thousands of years creating perfectly good models for production, location, manipulation, organization and consumption. The first computers, because of their low power, tied us very tightly to their hardware architectures. That time is now long gone and yet the computer world still holds onto it. Amiga is going to show the world that letting go makes perfect sense.
|
|
 | |
An AmiVerse can exist on a single hardware domain, such as a PC, it can share that domain with other AmiVerses or it can be spread out across a matrix of hardware domains.
Workstations, PCs, laptops, set-top boxes, games consoles, DVD players, smart TVs and cell phones will all still exist, but as hardware domains (a collection of hardware considered a unit), not as a hardware side of a computing coin. Ami decouples the user and developer experience from the hardware foundation. Hardware domains provide hardware services to one or more AmiVerses, and AmiVerses request hardware services but make no assumptions about the location, quality or quantity of those services. Everything is negotiated and brokered dynamically.
The AmiVerse is a closed environment. It knows everything that is inside, it is responsible for letting new elements and services in, and for letting them out, via the AmiGate and an immigration service. As a result, it is completely self descriptive. This descriptive feature extends far beyond content though. Ami makes very heavy use of a semantic mechanism. Not only does the AmiVerse know what it contains, it also provides a rich set of resources for describing what they can all do, what they are like, and what they require. Description is a key feature of the AmiVerse and is used as the foundation for organization, location, control, and interaction. This is achieved via Vocabularies and Interface Descriptions.
In traditional computer architectures, organization is tightly coupled to storage, the typical hierarchy of files and directories within a single filing system. The AmiVerse completely ignores that model. It presents a structureless sea of binary elements. Structure and organization comes from throwing questions into the sea and getting back the answers.
|
|
 | |
This querying service is supported by the vocabularies and interface descriptions and uses the concept of sets to process, persist and group. Thus, a user can create a set with the query, "all elements of content type 'gif'" called Gifs, and another set with the query, "all elements of owner 'Timothy'" called MyElements. As a set only contains references, in the form of unique element identifiers called AmiIDs, a single element can be a member of more than one set. Queries can be static, dynamic, transient and persistent. Instead of some arbitrary hierarchical distinction that allows for only one reference, users can now make associative and relational sense of their digital environment.
How they are stored is the business of the persistence service. It is irrelevant to anyone operating within the AmiVerse. Their concern is that when they have finished with something it is persisted, and when they want to use it again, it is available. By decoupling organization from persistence, the persistence service can now concentrate on doing a good job of persistence and retrieval intelligent caching, retrieval statistics, combining elements together, using multiple filing systems with each one tuned to particular types of element (large, small, streaming, static, dynamic etc).
There is no such thing as an application in the AmiVerse. Instead, users perform activities. They may fetch a piece of paper, to write an essay, an email, or draw a picture. They may listen to some music or play a game. They may decide to build an application.
Ultimately, all of these activities break down in service requests and provisions. A typical interaction might see an object ask the AmiVerse, via the service broker, for a printing service or a 3D service, or an Internet connection service. The service broker then queries its lists of service providers, considers the current state of the AmiVerse plus any special request directives, and then hands the answer, a set of none, one or more possible service providers. The object then picks one and starts dealing directly with it, as the service broker steps out of the way.
This has just been a small, very high-level description of Ami, the new girl in town. As you can see, she is both very different and yet very familiar. This is intentional. By escaping from the legacy albatross, we can start to make the digital age work the way people expect it should. When it works the way you think it should, then you work the way you should, and that is what the digital revolution is all about.
|
|