Separate parsing from rendering about canviz HOT 6 OPEN

The parsing of the xdot file (Canviz.parse()) is already separate from the 
drawing (Canviz.draw()); drawing the 
graph repeatedly will not need to re-parse the xdot file. However, it's true 
that parsing the draw attributes 
(CanvizEntity.parseDrawingCommands()) is done every time the graph is drawn, 
and I do want to take that out 
and make it happen only once at graph loading time, by converting the drawing 
commands into Path objects. I 
appear not to have filed a ticket for this before so thanks for doing so.

Great. I'll see if I can whip up a Python version of the parser producing 
"canviz" 
so that this can be used if desired.

I'm not certain what you mean for this to do. I consider Canviz a client-side 
in-browser xdot renderer, agnostic 
of any server-side scripting language that may be in use to build the graph and 
feed it to Graphviz. Though I 
have considered a server-side script for converting xdot into a more-efficient 
JSON representation for over-the-
wire transmission; see issue #56. Is this what you're thinking of? Or, what 
kind of output are you thinking your 
Python script would generate?

I think we're on the same lines - I wasn't sure whether the representation 
would be 
JSON or something Canvas-specific - it should just be possible to generate it 
outside of Canviz.

You're right, of course, that it should be possible to generate the JSON 
directly 
from a graph structure without an xdot intermediary. I've always generated dot 
code 
node-by-node and let Graphviz handle the target formats. Once the format is 
defined 
it would be easy possible to make it a target for Graphviz in situations where 
as 
much as possible should happen on the server.

Well, the Graphviz developers have mentioned thinking about having a JSON 
output format built into Graphviz. 
But until they do, I see no alternative but to have Graphviz generate xdot, 
then writing a script to turn the xdot 
into JSON. Thinking back to prior discussions, I think I remember now that the 
concern wasn't the size of the 
output, but the processing time for the browser to read the xdot.

That is my concern as well. For interactive graph manipulation there probably 
isn't 
anyway around this but I imagine there will be many cases where server-side 
parsing 
will be of significant benefit.