It's always struck me as odd that IP routes a packet to a transport-level protocol such as UDP, ICMP, or TCP and then lets that protocol handle routing it to an application process.
Since an application is likely to require a few different types of service for different parts of its operations, shouldn't the specification of the target application be more important than the transport mechanism?
Wouldn't it make sense to be able to send a UDP request to 'port 80' just as easily as you can send a TCP request, rather than requiring the web server to bind separate UDP and TCP listener sockets?
These chains of thought led me to design the MERCURY protocol.
Read more »
There's a little-known data structure with some useful properties; the Splay tree.
It's quite a useful data structure in its own right, but it also has interesting applications in data compression, and cryptography...
Read more »
NEON is the user interface system for ARGON. I've not designed what the UI will "look like", since I think that would be a stupid thing to do - different people need different UIs, especially when they have differing hardware (think mobile devices, wearable computers, and interaction devices for the blind, in particular). But what I have been designing is the UI architecture, by which applications will expose their interface in such a way that different UIs can map them to their available hardware.
Anyway, I've had some pretty similar ideas to Tuomo Valkonen - who has an idea called VIS. So I finally dropped him an email detailling my thoughts, focussing on how they differ from VIS:
Read more »
There are a lot of hobby OS projects out there. The Wikipedia article barely scratches the surface; I've come across projects to build Lisp-based OSes, 32-bit multitasking extensions to DOS, you name it.
Lots of people decide they want to write an OS. They look at a world dominated by Windows, with open source UNIX clones and MacOS bringing up the rear, and think: "I can do better". And they usual don't get too far. Even if you do write a full operating system, able to utilise a wide range of hardware and with all the applications home and business users need, you'll still have a hard time getting people to use it - because it's unfamiliar.
I'm proud to say that I, too, am writing my own OS.
Read more »
For TUNGSTEN, I plan to split the local storage manager into two layers; the physical manager and the logical managers. The physical manager takes a collection of block storage devices (such as hard disks), and a configuration giving advice on which disks to use for what, and provides an administrative interface for modifying said configuration and monitoring usage, and an interface to the logical managers. The latter interface provides access to a single unified associative data store; the local store is divided into regions for each volume mirrored on the local node (by a numeric volume ID), which are in turn divided into regions for each entity (by a numeric entity ID), which are in turn divided into regions for each object within the entity (by a numeric object ID), which may then be structured as the logical manager responsible for that object sees fit. The structure available to the logical manager within an object is a set of records, each with a key and a value. The physical manager provides the ability to create, abort, or commit transactions, and within a transaction, read, write, add, and remove records, including iterating through records by key range.
Read more »
ARGON | alaric | 
Tue 5th Sep 2006 11:15 pm | 
Comments (0) 
Subscribe