Apologies

Sorry for not updating my blog sooner. I have two draft posts saved that I meant to complete but I've been busy working on the project code and completing project deliveries. I'll try to recap where I left off.

After the Brandes algorithm (the last post) I worked on the first delivery which included pseudo-code for all of the metrics we are going to implement along with making some suggestions about possible GUI approaches. (6/8)

I had alread implemented a rough draft of some the metrics which needed to be updated with the new Graph API, which really did not take that much time.


On (6/15) the second delivery was due which implemented the graph-distance metrics. The actual metric turned out to be the easier part of this delivery, as there are still some framework issues that need to be ironed out (see the wiki page for some discussion).



On (6/22) the third delivery is due which has the implementations for ClusteringCoefficient and DegreeDistribution. Both of these are close to being finished as is, so this gives me some time to work on the framework issues that are arising, which all basically have to do with inputing parameters or displaying results to/from the user.



Here is a list of the main points which need to be ironed out as of now:

1) Parameterization: I think this is issue is mostly resolved. We create a JPanel (using Matisse) and have the Statistics return that particular JPanel when 'getPanel' is called. If the Statistics method 'isParameterizable' returns true, the controller displays the JPanel and cancel/next buttons to the user. One issue that arises in my mind is should the JPanel tie directly into the Statistics so that on each Gui event the Statistics Object is automatically updated? Or should the values in the Statistics object only be updated when the 'Next' button is pressed in which case we may need another function in the Statistics interface which tells the object to grab its parameters from the JPanel.

2) Progress monitoring: In my second delivery I had the Statistics object taking a ProgressMonitor object so it could update how much work has been completed. This is not a great solution as it ties down ProgressMonitor to the Statistics Interface. I've put some comments on the WikiPage about this issue. My understanding is that the Statistics Object will need to tell the rest of the system how much work it has completed to advance the progress meter. We want to do so in such a way that Statistics implementations do not HAVE to do this but they can so if they choose.



3) Statistics Cancellation: Mathieu has suggested using the Executors API for threading off each new Statistics implementation to a new thread. I'm spending some time investigating the Executor API. We can certainly call cancel on the Statistics implementations, however, we may want to kill the Statistics implementation if it is not responding. To do this I am under the impression that we may need to implement our own StatisticsExecutor class, as otherwise we may not have access to the particular thread?



4) Printing: I think that we can include a JButton on the report page which allows the HTML report to be directly sent to a printner. I've got this working to some degree, I need to finish the way it formats the page. Of course we will also want a way (JButton) to save the HTML report as well.

5) Parameterization & Reporting: For each metric I'll have to come up with a list of parameters and report items for discussion. What reports will be most helpful, should we make the list of reports selectable in the Parameterization, etc?