I'm working on the Summer of Code project "Visualization of STL Containers", the goal of which is to create 2D graphs of data stored in STL containers. (For more details, see the Trac link at the bottom of the email) The basic organization of the code is a "svg" class for working directly in the SVG format, and a "svg_graph" class that inherits from "svg" that the user uses as an interface. My current predicament is the design of the "svg" class itself. My personal view of the "svg" class was simply that it separates the handling of the svg document from the handling of the graphing logic. This was the way I designed the rapid prototype, and ostensibly, it worked. In my head, the "svg" class could technically be implemented without any external interface for users, and exist as a worker class. However, this doesn't seem at all ideal from a long-term planning perspective. I want to know if people would want me to spend some of the time of this project making the "svg" class act as a stand-alone (yet not fully implemented, obviously) SVG solution. Should it have a proper user interface? Should it be extensible to a full-blown SVG solution in the future? More specifically, are people looking for both a SVG manipulating class *AND* a way to graph STL data? There were suggestions of even treating the "svg" class as manipulating a document as per the DOM standard, which is indeed possible, but would require a complete overhaul of my current design, which I set up my current design in order to make optimizations on space and speed in the future. I see the obvious long term benefits of this method, but I question the benefit to the current project. I only have a finite amount of time in which to complete this, and it seems like it would take away from the stated goal. However, I'd be more than glad to implement a DOM if there were clamorous demand for this feature! Thank you for your time Jake Voytko Link to wiki on the project: http://svn.boost.org/trac/boost/wiki/soc/2007/VisualizationOfContainers