After a several year hiatus, DrawPile 0.7.0 is finally out. Get it from Github or Sourceforge. (Source code only release at this time, sorry.)
The major new features in this release are support for layers and the OpenRaster file format. Check out the Roadmap for what’s to come in future releases.
The more interesting changes have happened behind the scenes. The codebase has gone through a major re-architecturing and a partial rewrite. This diagram illustrates the old architecture:
In reality, the code was a bit hairier than that, with all sorts of interdependencies and kludges. However, one of the most troublesome parts was the BoardEditor class. There were two code paths for drawing: one for local mode and one for network mode. Every drawing tool needed two implementations, meaning lots of little nooks and crannies for bugs to hide in. Also, some features (like annotation baking) were not supported at all in network mode. While this architecture seemed like a good idea at the very beginning of the project, difficulties working with the code demonstrated that it was not. Rather than suffer with the old code, I decided to throw it out and start with a new design:
In this new architecture the distinction between offline and online mode is greatly diminished. All drawing actions go through a single code path, the only difference being that in offline mode a simple echo server is used instead of a real network connection. Aside from greatly simplifying the program’s structure, this architecture has the additional benefit of discouraging features that work in only one mode. As a direct consequence of this, annotation baking now also works in network mode and things like pasting images onto the canvas are now possible to implement.
Along with the client architecture, the server and the network protocol also received an overhaul.
Synchronization of the drawing board state in DrawPile works by routing all state mutating actions through the server to ensure a consistent ordering for all users. This basic principle has not changed, but the idea that the document being edited can be thought of as a sequence of commands is now made explicit.
Previously, the server was mainly just a traffic warden, receiving commands and redistributing them in a consistent order. When a new client joined, everything had to come to a halt until a state snapshot could be made and the new client brought up to speed.
The new server keeps a record of the session and synchronize a new client without disturbing anyone else. The old synchronization method is still support though. If the session history is exceedingly long, the server can pause the session and request a state snapshot to serve as a new starting point.
The new protocol is now more well thought out than the previous version. Like before, it is message based, consisting of drawing and management commands, but it is now explicitly divided into two sections: drawing commands and meta commands. The drawing command subset of the protocol is sufficient to handle all drawing related functions. The client could ignore all meta commands and the canvas would remain synchronized with the other users. The meta commands include everything that does not directly change the drawing board state, such as user login notifications and chat messages.
There is now also a clearer separation of concerns between the client and the server. For example, user locking and message filtering is now handled entirely server-side. Information about lock status is provided for the clients so they can update the user interfaces, but if a server says a user draws something, but the client thinks that user is locked, the server is in the right. Another example is state snapshot generation. Snapshot generation is now delegated (almost) entirely to the client, rather than the previous approach where the client only provided a bitmap of the drawing board contents.
In summary, DrawPile’s new architecture should make further development much more easier. For a more in-depth look, check out the protocol design document.