An update on development of Springy

Dragan, posted May 14th 2010 at 11:00AM

After a bit more than two months of silence, it’s time to give an update on current development of Springy. In short, it’s going fine. It’s moving forward slowly (for the reasons I’ve already mentioned here), but steadily and in the direction I want it to go.

The effort made in the past two months can be roughly divided in two parts.

The first one was about implementing robust and reliable, but still fast automatic archive type recognition. As is already the case now, Springy doesn’t assume a particular archive type based on any file metadata or file name part (extension, Type/Creator code, extended attributes…), but really tries to determine whether any file thrown onto it is an archive or not (examining its certain portions), and if it is, which exact type of archive it is. This doesn’t sound like a very difficult task to accomplish, and it really isn’t, but I was playing a lot with different implementations in order to find the best compromise between reliability/robustness and speed. And I think I’ve found one. In the meanwhile, the list of supported archive types and compression methods has grown. Apart from what Springy already supports, the list also includes some new formats (SITX, AR, XAR, MTREE...) and new compression methods (LZMA, XZ, RPM, UU,...). Some more will come along the way. Even multiple stacked compressions are supported, for example a direct peek into GZIP compressed TAR archive which is than again compressed with BZIP2, etc. This combinations are not very common in reality, but they still can occur, especially uuencoded variants like TAR.GZ.UU, TAR.BZIP2.UU and similar.

The second part of effort was about choosing the right data structures to represent a hierarchical list of files (and all their relevant attributes) in an archive, hence to define the archive model. Again, I was playing with different implementations in order to find (in my opinion) the best one which will be used to build upon. The goal is to make archive processing operations and contents displaying in the UI fast and flexible, but with usage of as less code as possible. The chosen implementation differs to a great extent from the one used in the latest version of Springy (1.6.1), but some preliminary testing of UI display operations shows it’s already a bit faster. It also will take advantage of some Apple technologies which were not present or not mature enough when the current model was set (like Cocoa bindings, for example).

With these things implemented, I can move to first implementations which will include view layer and start working on application UI and relevant details. I must admit I find this part a bit less interesting to develop, but I hope foundations I’ve already made will make it smooth and pleasurable. I also plan to make a practical use of the things already implemented and, like I’ve already promised here, they will find their way into Spotlight Importer and QuickLook plug-ins. These developments will go in parallel with the main application, so don’t expect them available immediately, but they will be available very soon.

This is also a good opportunity to mention that there will be one more update of the current version of Springy. It will be possible, as the (missing) source code is not required. I will only update help system consisting of HTML files. Essentially, the Springy Help system is still the old one, which appeared first in version 1.5. I wasn’t really thinking of updating it, but quite often I get questions about enabling and using System Services provided by the Springy application running under Snow Leopard. In my opinion, Apple hasn’t done a good job highlighting this and apparently a lot of people have no idea about many services available but not enabled by default on their systems. The updated Springy Help system should tackle that problem and also provide descriptions of all new features available in version 1.6 and 1.6.1. I expect to release this update by the end of this summer, as it is not urgent.