Jawas 2 : The Revengening
Last night I pushed up the first days hacking on Jawas 2. This is now the 8th year of work on this platform, so I have decided to do yet another rewrite from scratch. The primary reason for scrapping the old code is a shift in focus. The original server code base focused on doing things in scripts and databases, and was tooled heavily towards making that sort of server side processing easier. But in the past 8 years, my design choices have heavily shifted my focus towards doing all of that processing on the client side.
Jawas 2 will be a next generation application server, with a view slanted towards the unix tradition. Its primary role will be to distribute documents across a group of servers which function as a single logical entity. It will do this using HTTP/1.1 exclusively to perform synchronization between the nodes in a group.
The implementation details on the backend will be primarily non-blocking IO with kqueue based event driven request processing. The underlying data store will be a tmpfs / ram file system (HFS+ on Mac, UFS on BSD), with only open, close, and mmap used to access contents. Writing to the sockets will be handled by writev, and iovecs will be used for all parsing. Each client connection will be forked into it's own process, and the process will persist as long as the socket is kept alive.
The important features that Jawas 2 will focus on will be full support for HTTP methods, especially the CRUD suite. It will also support request pipelining, chunked transfer encoding, and gzip compression. Finally, it support distribution by relaying messages to all nodes in a user defined peer group. This will enable building applications that scale well on unreliable nodes.
What Jawas 2 won't do that 1 did well: it won't have server side processing and integrations with scripting languages; it won't have automatic database bindings; it won't do fancy URI routing and provide a base application framework.