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?
From a personal perspective, yes please :-)
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!
My gut feeling is to keep it simple at this stage: make the svg class "write only" so we can use it to create basic diagrams, but can't open/modify existing ones. I don't want to distract you too much from your core aims of visualising data - and a fully fledged DOM is probably unrealistic within the timeframe anyway - but it seems a shame to have this class, and not have it useable at a user-level. HTH, John.