I visited the website of ACCESS Co., a company that I’ve always only heard of in connection with the unfulfilled hope of PalmOne’s PDA users, the permanently soon-to-be-released Access Linux Platform (ALP) – to see if they have abandoned it or not yet. The status is that they haven’t or at least are not admitting it, currently the FAQ says Q1 of 2007 and the whitepaper says Q3. Here’s what I could gather.
They already released something called “application framework” for ALP, a project named Hiker. Current Hiker version is 0.9.1 and the 0.9 sources can be downloaded too, both are 2006. It is a 3.5 MB tarball mostly under MPL, containing: a short doc about building the thing and an ALP whitepaper PDF, code in C partially something that may be an early “application framework” and partially lots of empty stub functions, a reasonably small amount of C++ code (unit tests) and doxygen generated docs for that – not informative. Not all of ALP is going to be opensource and there’s no information on the status of the other parts. Of the pretty “software stack” diagram found in the docs, around.. one eighth? of the bubbles is orange, designating opensource parts in ALP. About half of the diagram surface is covered by popular FOSS project names, so that’s not so bad. The build system for Hiker is autotools based and the whole package has a few dependencies like sqlite, glib, dbus.
What’s that application framework? It is supposed to be a set of libs including UI (this part is not present at all in current version), IPC, security (these two constitute most of the tarball), settings registry, etc, divided into daemons with names known from PalmOS (Application Manager, Attention Manager…). I found no hints about how the UI will look, the UI toolkit is called MAX. Apps running on ALP can be: MAX native, GTK+ native, PalmOS m68k .prc’s (what about ARM?) or Java. The whitepapaer admits many UI ideas are taken straight from PalmOS, hopefully the good ones. Hiker doesn’t depend on GTK, but there’s some code that uses GTK, a thing called Native Process Launchpad Daemon.
Apart from the system libs ALP is supposed to manage packaging, packages are called bundles. Looking at the code, bundles appear to be cramfs images with names ending in .bar, and containing one obligatory XML file describing the bundle. Two alternative formats (schemes) are allowed: ghost (?) and java .jar/.jad’s for which the Manifest.xml is generated on the fly. Installation involves loop mounting and some SQL queries. Sandboxing is mentioned too.
IPC has separate APIs for C and for C++. The whitepaper says that writing ALP apps is easy as making Java apps.
All different formatting styles are present in the C code. And here’s a sample from NLPD:
// // This is just some magic I found // via google. Man pages do not // cover it. // if (prctl( 15, NewName, 0,0,0) != 0) returnvalue = 1;
Dear ACCESS, prctl() has a man page on my system, and I can send it. Also, the call alp_prv_strcpy2, that is introduced “because C strings a pain in the tail”, as we are told in the comment, is already in glibc known as strndup().