High-level Design

With any new idea, we look at customer, technology, and business aspects of whether it’s something that can work. It takes time (often, a lot of time) to explore all the ideas and tradeoffs involved. Feedback of any kind is a great way to make this process of settling on the specifics go more quickly, and the decisions better-considered and longer lasting. So we’ll look again at technology.
Chartpart component diagram

For chartpart, the high-level design should be simple — making use of existing components as much as possible. The actual application is a stable, well-thought out API for requesting a chart (A URL which fully describes it), the code to transform a GET request into a chart image, plus a nice helper form to create those URLS, and other information.

The Gruff library is where the heavy lifting of charting happens, and a few small changes were done there already and passed back to Geoff Grosenbach, Gruff’s author. The chartpart app (as thin as it is), is not open source. But enhancements to all the libraries under it will be (and must be, in the case of GPL or other licenses) passed back.
Partially because of Ruby’s dynamic nature and good cross-platform tool and library support, there’s another interesting thing to note about this diagram — there are a lot of fundamental components at the bottom of the stack (e.g. what OS it runs on), that can be entirely substituted. In fact, chartpart has been developed on a mix of Windows, Linux, and Mac platforms as I’ve played around at finding an environment that I like best (I’ve settled on a MacBook). And the actual hosted environment of chartpart.com is Linux today, but might be Solaris tomorrow.

Anything wrong with the approach or diagram? Any thoughts or concerns about mixed license models?

Post a Comment
(Never published)