The first beta of Jython 2.2 has been released! Jyhon scripting is something that I’m planning to add to RvSnoop so I’m quite interested in this, especially given the current focus of development is making the codebase easier to understand for new developers, I’ve looked at it fairly recently and at the moment it’s quite a tangle!
A new stable build of RvSnoop is available for downloading (it was actually released back on the 12th, but I forgot to post about it here and have been away from the internet for a few days). New in this release:
Now that the 1.6 release of RvSnoop is out of the door (OK, 1.6.1 ‘cause of a wart inthe original release), there are certain features that I’d like to see added, and for the 2.0 release I want to have in place a foundation that will make it easier to add these.
A full list of features can be found in the plan file in the RvSnoop Subversion repository, but some of the big ones that will impact the overall architecture of RvSnoop are…
I’m going to migrate the record ledger to being persistent, there are a couple of options here as to how this will be handled: flat files, a combination of flat files and Lucene based indexes, or some kind of JDBC backed store.
One option would be to make the persistence mechanism plug-able, this would also ease the use of an all-in-memory storage system, like the one that is currently used (which is useful when you just want to use RvSnoop as a graphical replacement for tibrvlisten).
I’d like to add the ability to run RvSnoop without the UI, this would be based on loading a pre-configured project. Combining this feature with a JDBC backed store this could be really useful for auditing and logging messages.
I registered the emssnoop.org domain at the same time as rvsnoop.org, and there has been a project on SourceForge for a while, even if it hasn’t had anything checked in to it yet! An open question is whether to try for generic JMS support or just work with EMS directly.
It would be nice to be able to cleanly extend RvSnoop if required, without going back and modifying the main code base.
All (well, most) of these features point to a need for an extensible plug-in system, Eclipse has shown that a good way of architecting a desktop application (or any application, for that matter) is to build it entirely from plug-ins wrapped around a small core.
So, the upshot of this is that I’m planning on migrating to a managed runtime, probably OSGi, for the 2.0 release. I’ll talk about this more in another post. In particular, what’s the cost/benefit ratio of using this type of runtime; and which runtimes are good?
A new development build of RvSnoop is available for downloading. This release contains all of the features that will be in the finished 1.6 release, due out sometime next week.
Changes from the last development build include:
The only things left to do now (assuming no new bugs are found) are some additional testing and documentation updates.
A new development version of RvSnoop is now available for download. This version adds:
And also fixes some bugs involving the screen menu on Mac OS X. The save and restore messages option writes the selected records from the ledger to a ZIP based binary file format (it’s the same format that is used internally by the copy and paste mechanism). The format has also been enhanced to include subject information for the messages, as this is stripped out by the raw Rendezvous library calls.
Apparently (according to this) Mac Office is 30,000,000 lines of code, that’s a lot of code to try to keep bug free! Out of curiosity, I downloaded a utility to count lines of code and found that RvSnoop is only ~7,000 lines of code. That’s only counting non-comment lines, I don’t know how well commented the MS codebase is.
Not that there’s any real comparison in functionality between the two of course!
For RvSnoop I’m currently working on adding namespaces to all of the files that are used to save the application preferences and also the project files. This is a Good Thing in and of itself, as it allows me to use XML Schema to validate and document the files formats. But, more importantly, it gives me the opportunity to refactor as I go alond, the general plan is to make the projects in the next release be based on directories rather than a single XML file, this will allow me to use a disk based storage mechanism for messages so that they will be persistent across sessions.
At the same time, I’ve taken the opportunity to include some of the Apache Commons libraries in the build. There were (well, still are) a number of small utility classes scattered around which I’m planning on replacing with the versions from Apache.
One side effect of this is that the build is increasing in size, to help control this I’m going to remove the Berkeley DB dependency from the build. I was origiannly planning to use this for the on disk message store but I’ve changed my mind here. My current thinking is to just write the messages out to files but to have a set of indexes (probably built using Lucene) as well for searching and sorting.
There should be another (alpha) release out later this week with the Commons and Berkeley DB changes complete, and a release next week with the new project structure.
Although it’s an open source project that anybody can help out with, in practice RvSnoop is developed by me at present. However, a couple of people have asked — - either in the forums or by email — - what the current development status is. Well, in a word, it’s going slower than I had planned!
However, I’ll start posting to this blog a little about what I’m working on and what my current plans are, and also try to start making more frequent releases.
I’ll rearrange the distributables slightly as well, given the speed of most connections these days I no longer see the point of keeping a binary only download so I’m just goint to include the compressed source and API docs will all of the releases, this will be labelled as the RvSnoop Stable release.
I’ll make more frequent releases of the code that I am working on as a RvSnoop Development release. But first, a little explanation of what you can expect from these unstable releases. I’ll post later about my plans for the upcoming releases.
Projects use diffferent terminology for there release schedules, here’s how I’m using the terms.
If a release is labelled alpha then it means that I am still adding new features and working on major known bugs. Once the release is feature complete and all of the major bugs have been squashed I’ll go through and clean up all of the strings, finally I’ll spend some time cleaning up any glaring UI problems.
Once this is complete I’ll relabel the release beta.
Moving forward one of the main points about the beta release is that it will be considered to be a string freeze release. I’m aiming for release 1.7 to be fully prepared for internationalization and hopefully some of the people who have been using RvSnoop will help out with translations.
Also at this point the UI will be basically finished, so the beta releases are for testing and minor bug fixing. Also during this phase I will run all of the analysis tasks (currently only PMD, but more are planned) and clean up whatever they reveal.
I’ve noticed a neat feature in Path Finder where it changes the date format used to display time stamps in the main table based on the width of the column. In RvSnoop I was allowing the user to set a preferred format as a configuration option, but this seems much better.
It turns out that this is pretty easy to achieve in Java, just use the following class:
public class DateCellRenderer extends DefaultTableCellRenderer { // Or load these from a user preference... private static final DateFormat[] dateFormats = { new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS"), new SimpleDateFormat("yy-MM-dd HH:mm:ss.SSS"), new SimpleDateFormat("MM/dd HH:mm:ss.SSS"), new SimpleDateFormat("HH:mm:ss.SSS"), new SimpleDateFormat("HH:mm:ss.SS"), new SimpleDateFormat("HH:mm:ss.S"), new SimpleDateFormat("HH:mm:ss"), new SimpleDateFormat("HH:mm") }; private int currentWidth; private Font currentFont; private DateFormat currentFormat; private final Date date = new Date(); public Component getTableCellRendererComponent(JTable table, Object value, boolean isSelected, boolean hasFocus, int row, int col) { DateFormat format = getFormat(table.getColumnModel().getColumn(col).getWidth(), table); String displayed = value != null ? format.format((Date) value) : ""; return super.getTableCellRendererComponent(table, displayed, isSelected, hasFocus, row, col); } private DateFormat getFormat(int width, JTable table) { Font font = table.getFont(); if (currentWidth == width && currentFormat != null && font.equals(currentFont)) { return currentFormat; } currentWidth = width; currentFont = font; FontMetrics metrics = table.getFontMetrics(font); date.setTime(System.currentTimeMillis()) for (DateFormat df : dateFormats) { if (metrics.stringWidth(df.format(date)) < width) { currentFormat = df; return df; } } } currentFormat = dateFormats[dateFormats.length - 1]; return currentFormat; } }
You will need to register it with your JTable via myTable.getColumnModel().getColumn(0).setCellRenderer(myRenderer); and away you go. You can have more or less format options by altering the static array in the class.
I’ve taken over pretty much all of the development of the rvSnoop utility now, the first major new release has been put out today with a number of changes in it. Here, briefly, are the plans for the next few versions:
I’ll have more plans once I get to know the code a little better.