Anida is the cumulation of several years of research and development in alternative approaches to web browsers and general application development and media delivery. The project was started to work through the problem of embedding web technology into high end mobile and other embedded devices. Embedded browsers based on desktop browsers especially the WebKit engine have become increasingly common as processing power has reached the point that its now possible to utilize standard web browser engines in devices ranging from mobile phones to televisions.
The general approach is to embed the browser into and existing platform often a cut down desktop OS such as linux. In some cases like Android a embedded OS rivaling desktops in complexity and footprint is used. Regardless the current approach common in all mainstream higher end embedded devices can be simply characterized as stuffing as much desktop like software as possible into and embedded device and following the traditional approach of allowing it to bloat as hardware capabilities improve. Effectively the same path desktop systems have taken for decades with each improvement in hardware capability rapidly drowned in ever more software.
The web and to some extent web browsers have evolved along a different path a fairly powerful language interpreter and visualization system allows for and alternative division of software between the platform and application. Instead of stuffing the capabilities into the platform new functionality is pushed to the website leveraging the fairly slowly changing web browser. Both approaches offer and ever richer user experience but for network connected devices the browser approach offers and immensely richer experience without causing massive bloat to the platform. Surprisingly this advantage of a web like approach simply has not been adopted by higher end embedded devices. Instead in general the browser itself becomes one very large application offered on the platform. Thats not to say that there is not a lot of interest in “webtops” for embedded devices and certainly examples exist however very little seems to have been done to really develop this fascinating approach to higher end embedded device interfaces.
One obvious reason is that the desktop browser engines where written for the desktop and assume that the underlying platform is itself fairly rich. Thus the obvious approach of providing a desktop like environment first then porting the browser has become common. Certainly reasonable as a first pass however that does not mean its the only possible approach.
Indeed Anida takes and entirely different approach to the problem. First and foremost it recognizes that the browser itself is close to being capable of providing the entire user interface. In addition other media types such as video and flash or OpenGL can be integrated to provide and even richer user experience. In order to do this without recreating a variant of the desktop to embed the browser a lightweight frame work has been created to allow the WebKit engine itself to provide the functionality to support not only a browser but any sort of application. In effect WebKit is ported to run on WebKit.
The original approach was to modify webkit itself to generalize its capabilities to allow the browser to be self bootstrapping. Although this approach was technically successful it suffered a number of problems. At the heart was the simple fact that browsers are optimized to display HTML. This fact is not exactly shocking. Hacking the rendering engine to generalize it resulted in all kinds of interesting and unpredictable bugs in the ability of the engine to render HTML. Despite this setback it was clear that a browser like engine was more than powerful enough to serve as the platform for a browser. With this realization Anida was born. Instead of taking the traditional approach of creating a desktop like environment a minimal browser like environment sufficient to support WebKit was created and used to port the core WebKit engine allowing higher level functionality to leverage the capabilities of the Anida engine and WebKit. Thus the platform itself was simply a lightweight browser. Anida is thus a browser capable of having a desktop browser engine as a plugin. For a long time the project had the catchy name of Generic Player. Later it was renamed Anida which means nest, shelter or home in Spanish.
Although Anida is much smaller than full blown browsers with a size of a little over 1 megabyte it packs a lot of capability itself. This size is for Anida only and does not include the supporting libraries such as cairo which are a subset of those needed by WebKit. Despite this its obviously substantially smaller than frameworks based on cutting down desktop system or building equally complex non browser centric frameworks.
The following basic functionality exists in the Anida engine.
A dynamic runtime system and language that allows integration of modules written in C,XML,Javascript and other languages to transparently call each other.
A still incomplete implementation of DOM Level 3.
Basic graphics, Layout and rendering.
Dispatch of DOM events.
Ability to extend WebKit with arbitrary custom tags.
Ability to define and implement tags in C and XML/JavaScript.
Garbage Collection required to deal with the dynamic nature of the system.
Since the platform is now itself a mini browser thats easily programed and embedded into WebKit its impossible to even know whats possible. Next since its based on a flexible runtime allowing integration of other engines even more is possible.
With this approach browsers are no longer opaque complex difficult to modify engines relegated to experts but easily extended using technologies common in browser content programing. Your web developer is now empowered to be a browser developer.
At the heart of Anida is a fairly simple runtime system based off of ObjectiveC, Java and Javascript and general interpeter concepts. However the engine is not specialized to a single language but instead implements a sort of virtual language sufficient to allow any language or media engine to call any other interface exposed in Anida regardless of implementation.
I call it a interface implementation language. Unlike traditional interface languages such as Corba which are compiled into a traditional programing language Anida specifies the Object model and calling conventions concretely using a subset of the C programming language. The runtime provides advanced functionality generally only found in scripting languages. Although its not and exciting language to program in its sufficient to meet its goal of allowing the merging of disparate technologies and languages into a powerful platform.
In a sense its close to the plainest or simplest language possible which can also express the key modern object oriented concepts and support a DOM no more and no less. No glitz and glamor but yet a lot of capability in a small package. Indeed its simple enough that the basic interface definition language is JSON which is powerful enough to write Anida object definitions.
You can think of Anida as a JSON interpreter used to bootstrap a basic XML DOM thats then used to provide the platform for WebKit.
Beyond the basic platform Anida follows and implementation approach similar to its bigger siblings. And XML document is parsed and expanded or bound to the tag implementations generally these are visible. In WebKit this is done by backing the Document with a shadow rendering tree. In Anida the approach is similar however the render tree is itself simply and XML document. Thus the rendered or interpeted XML document is simply another XML document. The primary difference is that the backing documents tags have additional methods to paint and accept events. The basic system first passes events through this back document then to the front or original document.
Originally XBL was going to be the target language however the specification especially of XBL2 is complex and difficult to implement. By simply assuming a secondary binding document created by copying template definitions into the binding document one can achieve the aims of XBL without the complex implementation. Often these render tags are actually WebKit frames rendering a custom document that exports an Anida interface. However any technology that can be supported by the basic graphics engine and event system can be used from simple C language implementations to embedding other engines such as OpenGL and Flash.
Next since WebKit has been modified to allow custom tags defined in Anida to be rendered inside a Web page any Anida document is itself now accessible inside the WebKit engine. Since the binding between the front document tag and its back document or binding document representation is done at runtime different bindings can be used for different platforms or even different applications.
Anida Runtime:
The runtime itself is very simple and is based on the reduction of a function to two parameters a type info argument and a data argument. The function prototype is:
typedef void (*function)(Type* type, void* args);
The arguments are marshaled as a C struct with the type information providing the offset and types and size information of the structure. So our runtime simply retains the C language structure information normally discarded at compile time.
By using simple C structures calling from the C language is transparent and natural. Other languages such as Java and Javascript make use of the runtime type information to marshal and unmarshal the arguments into the language specific types. In general these gateways can be written once to provide transparent call support. We adopt the Javascript language convention that all objects are also functions and we don't make a distinction between the two. Traditional objects simply have a no-op function if executed. Closures are implemented as pre-allocated call frames with some of the arguments initialized at allocation time thus closures are naturally supported by the system.
In addition to the structure layout the runtime type contains a list of methods which are executable member types not part of the runtime allocation. These are basically virtual functions. Finally it contains the function pointer to a function that takes the type and opaque argument list as parameters.
This is all the runtime manages directly concepts such as inheritance and overriding of methods are extensions to the core since they depend on additional members such at type pointers and super class pointer in the definition of the structure. Additional modules such as the DOM module implement object oriented concepts on top of a basic single inheritance core object. For the DOM attributes are by default mapped to members of a C struct. Additional support for Getters/Setters allow more complex relationships between attributes and the DOM element.
Surprisingly this fairly simple runtime is all that is required to implement concepts generally associated with high level languages such as JavaScript, java or python. In addition the runtime includes module discovery and dynamic loading support.
On top of this runtime we have implemented a few core modules that implement basic ui abstractions such window and canvas. In addition we have partially implemented a DOM level 3 API.
The currently implemented modules list.
Window API implemented on DirectFB and X11 and GTK.
Canvas API supporting drawing regions and events.
Rootless X11 server using the canvas API.
DOM level 3 API including a single inheritance object model.
WebKit ported to run on the abstract canvas API.
Support in WebKit to expose tags implemented using our DOM as custom tags in the WebKit DOM. Support for loading lightweight HTML and SVG viewers as custom widgets.
Support for transparent calling to and from JavaScript using the runtime type system.
Sample widgets such as scrollbars buttons etc that implement C language and JavaScript API's transparently via the runtime using HTML and SVG and JavaScript for the implementation.
Anida is hosted at sourceforge:
Currently its only available from source control.