Open Bug 154612 Opened 22 years ago Updated 17 years ago

Use client-side maps for dependency graphs

Categories

(Bugzilla :: Dependency Views, enhancement)

x86
All
enhancement
Not set
normal

Tracking

()

People

(Reporter: ellson, Unassigned)

References

(Blocks 1 open bug)

Details

Opening a new bug for this in reponse to Comment #56 of bug #120537

  "Please do file another bug to use the GraphViz module, as well as use a
client side map file, too, while you're at it, so that we don't need these
temporary files." - Bradley Baetz  

Also related:  bug # 14500

Question for Bradley:  What "GraphViz module" ?

Some form of temporary files will be required as long as images and maps
are loaded separately by the browser since, for consistency, both should be
generated from a single graph that can't be updated between generating the 
image and the map.   SVG would not require temporary files because the
format descibes both the image and the hrefs in a single file.

Even with SVG, it might be a performance gain to use some kind of caching of the
output graphs since the graph layout process is fairly expensive
computationally.   Webdot uses caching to satify both of these needs.
(However, webdot's cache cleaning strategy needs improvement.  I'm going to work
on that for the next webdot release.)

Client-side maps could be provided by processing an html template and
adding the map and image-size information.  Much like the example at:
  http://www.graphviz.org/cgi-bin/webdot/webdot/clientmap.html
This is done for dot - see bug 134571. Its not done for the case when we use a
remote websot server, though, but I don't think we can do that in this case.,
though.

The module I was referring to is the perl graphviz module - currently we
generate the (temporary) input file and call webdot directly. Using the GraphViz
module means that we wouldn't have to do that. The GraphViz module uses
IPC::Run, while we just use system, so hopefully that would have  abetter chance
of working on windows, too. See bug 134565
I gather you're referring to:
   http://theoryx5.uwinnipeg.ca/mod_perl/cpan-search?dist=GraphViz-1.5

This looks like a good API, but you realize that underneath its still 
running "dot" in a pipe?   Perhaps the author's intent is to provide a tighter C
binding later (like tcldot's from graphviz used by webdot).
With luck he should be able to slip in a C binding without changing the api.

Currently he is building graph data structures in perl, and again in dot
when it is run externally.  A closer binding is more memory and cpu efficient
because you only build the graph structure once.

This all may not matter for Bugzilla.
Right, but since what bugzilla is doing is creating data structures, and then
calling dot via system + output redirection....
The tcl stuff works because it links to a common library file built at the same
time graphviz is - there is not, AFAICS, a public library for using grpahviz.
Right, but I'm the tcldot + webdot + graphviz(parts) developer, so
if you wanted (e.g.) a libdotneato.so installed as a public library
that could be easily arranged.

However, I'm not much of a perl hacker and I've never written
a perl extension, so I might need some help if a C binding for
perl is needed.
I've never written an perl XSmodule either...

What about giving graphviz an option to produce an html client side image map,
though, directly? Its possible to go from -Tismap/-Timap to one (bugzilla does
so), but its not convienient, and graphviz has all the data to start with, anyway.
OK, you've got it.

(It only took 4 lines of Tcl to fix this up.  It took a lot more than 4 lines
of C to generate it :-( 

The change is in CVS now, it will be in tomorrow's snapshot sources in
http://www.graphviz.org/pub/graphviz/

Currently node URLs are OK, but substitution of \N in edge URLs
doesn't work right.  I'll fix that tomorrow.
The User Interface component now belongs to Gerv.  Reassigning all UNCONFIRMED
and NEW (but not ASSIGNED) bugs currently owned by Myk (the previous component
owner) to Gerv.
Assignee: myk → gerv
Reassigning back to Myk.  That stuff about Gerv taking over the User Interface
component turned out to be short-lived.  Please pardon our confusion, and I'm
very sorry about the spam.
Assignee: gerv → myk
Target Milestone: --- → Future
Blocks: 154500
QA Contact: mattyt-bugzilla → default-qa
Target Milestone: Future → ---
Assignee: myk → ui
Component: User Interface → Dependency Views
You need to log in before you can comment on or make changes to this bug.