Graphviz from URL
tgirardi opened this issue · comments
Is gravizo capable of rendering a graphviz code contained in a certain URL?
The above url contained in the "url" parameter is the raw URL of one of my Gists.
If not, I think it would be a very nice feature.
An interesting use case would be to make a Gist with the graphviz code and then use gravizo to render it. Different people could collaborate to the graph by making Pull Requests to the Gist and each new version could be rendered using gravizo.
Actually is not posible, but I need to think about it, because It will fix the url limitation. The one big problem we have now it's that gravizo uses a CDN to forget to render the image every time. If the image url doesn't change then the image neither. Gravizo could render the new gist version if the gist url changes, but then you should change the image link in your original document on every change. Does it make sense to you?
Yes. Perfect sense.
The URL change (e.g. ?version=2) could be a simple workaround.
I can think of a solution, but it would need some changes in gravizo code that are probably not just a few lines:
Github sends an Etag header which effectively changes when you make changes to the Gist (and obviously persists while it's still the same).
Gravizo could keep a record of that Etag for each gist ID. If the tag is still the same, then it send the image it already had. If not, it re-renders the graph.
Does it sound like a good idea?
@tgirardi but the request will not arrive to Gravizo, the CDN will not call Gravizo if already has a cached image. With anticache (e.g. ?version=2) will fix the problem, but then you should update your reference on every change, right?
It will depend on the Web server's settings. Gravizo.com could send the right http headers (for the first petition) to avoid browsers from using the cached image without asking gravizo first. I'm not sure how CDNs work in that matter, but surely they can behave in a similar manner.
But then, on every image request, client will call Gravizo, then gravizo will call Github, then will render the image. This will affect performance and usability.
I think will be better to create some kind of api to clear cache, to call it from a gist webhook or something like that, but github has disabled it https://developer.github.com/v3/activity/events/types/#gistevent
That's true.
Also, Could Github block Gravizo in a certain way after noticing a high amount of requests from the same server? (probably this concern should also be addressed even if something is made in order to reduce the requests sent to github to the minimum necessary amount).
So I agree with you about taking in consideration the performance implications.
The API idea sounds interesting, but apart from the fact that the event doesn't exist anymore, the other disadvantage would be the need to configure a webhook or some kind of integration between the Gist and Gravizo, for each new Gist.
The anticache parameter (e.g. ?version=2) seems to be the best option right now.
Furthermore, I was thinking about the option of providing an URL parameter to tell Gravizo that it must force a re-fetch of the Gist. But, it could lead to abuses: many users will surely add the parameter for all their requests, even for requests that are hard-coded inside some documents. For example: someone could use something like  inside a markdown document, which leads to a re-fetch every time the document is rendered (Github wouldn't be a problem because it seems that they fetch the image just once and then store it in their servers and, for future requests, provide it from there). The anticache parameter wouldn't produce this problem, because the URL must be manually changed every time a new version is needed.
Other similar option would be to provide the user a way of telling Gravizo that the cache for a certain image is stale. It could be something like http://gravizo.com/clear-gist-cache?id=.... The user would need to call that URL after each modification of his gist.
The advantage for the user is that he doesn't need to update any of the references to the gravizo URL. This could be very valuable if he included the same diagram in multiple documents, using the same URL (I'm not sure if it would work for Github though, because of their internal image cache).
It will depend on the Web server's settings. Gravizo.com could send the right http headers (for the first petition) to avoid browsers from using the cached image without asking gravizo first. I'm not sure how CDNs work in that matter, but surely they can behave in a similar manner.
thanks, I will investigate how e-tag, 304 and so on, works, and create something to allow this without lost performance.
@tgirardi I have just updated Gravizo with this enhancement. It also support to embed multiple graphs in the same file even including the image reference in the same gist file. It is a beta version but it should work.
You can refer a public url with: http://g.gravizo.com/source?<your url raw url encoded>
for example:
To include the code in the same file you refer, you can include your graph code in a comment and then refer the raw file but adding the mark where the graph is included. Gravizo will read the code between two of this marks.
http://g.gravizo.com/source/<mark>?<your url raw url encoded>
Example:
<!---
gravizosample
digraph G {
main -> parse -> execute;
main -> init;
main -> cleanup2;
execute -> make_string;
execute -> printf
init -> make_string;
main -> printf;
execute -> compare;
}
gravizosample
-->
Here is a gist example also: https://gist.github.com/TLmaK0/0e4c3004c92e8e41405c
Also you don't need to escape your graph, you can use real dot, plantuml, etc, so It will open new posibilites to Gravizo.