#amoebaOS

Connecting...
Say Hello ▶

amoebaOS Bandwidth, Direction and Tech

Feb 19, 11

Note: I posted this to the forum, but I feel it should be a little more public than being buried in whatever thread that was.

amoebaOS is not like a traditional web application where your front-end code requests small bits of information from the server customized to its needs. Instead, it implements a remote Filesystem - which means things like saving or retrieving settings or content is done on a file-level. If you wanted to know what color for text someone has specified in settings in an app, you have to pull down the whole settings file just to get at that little bit of info.

There's a solution though. Much more aggressive caching is going to help with this. Right now apps are always requested from the server as if there might be changes (it's possible, because you can run apps while editing them). With the addition of two-way communication with the server, this will become completely obsolete. If a file is open, the OS will then be sent notifications if changes are made to that file (until it is closed). That means the app launcher doesn't have to ask the server for an app it already has, it can already tell if the app has been modified or not. The same is true for files. If an app is reading preferences from a file, it will be able to request that file a million times and the file will only be downloaded once (assuming it doesn't change). 

Also, another really cool feature coming is client-side file awareness. Like I talked about above where the server tells your browser a file has been changed, your browser will also be able to do the same. If an application saves a file, the system will store that as the cached version of the file. Then when something else goes to access it, the cached version is used. It's going to increase RAM usage a bit, but there's a solution for that too!

WebkitSQLite and HTML5 LocalStorage. Right now, when apps want to store a big chunk of data, they store it in-memory (seem a bit weird? it's actually the norm for web apps). So, to aid in killing this silly pattern, I'm going to be writing an extremely generic sandboxed cache API. Each application gets it's own cache when launched, and it can storeany information in that cache (literally anything: files, prefs, JSON, etc). When the application is closed, the cache is cleared. In Chrome, Safari, Firefox, Opera and IE9 this cache will use no RAM at all. This will be a massive reduction in the overall memory footprint of amoebaOS. In Internet Explorer 8 and below, the cache will be store in-memory because the read/write speed on their DOMStorage mechanism is terrible.

Anyway, the cache stuff is actually a pretty quick thing to add so count on that coming sooner than later. The filesystem additions, new Filesystem API and push API are already started, I just need a big chunk of development time in order to finish and test them (it's crucial they work perfectly and don't break compatibility with current apps).

About :

Comments
tony#
Cool!
shekhar#
very nice blog
Leave a Comment

Post Comment