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.
The development of Springy 2.0 has started
Dragan posted Mar 1st 2010 at 2:40PM
The recent period, since the unfortunate event described here, was very frenzy for me, both on professional and private front. But that time wasn’t spend for nothing. I set-up the necessary infrastructure for the new Springy development; the whole Development folder (where I keep all my projects, sources, documentation and other development related stuff), while being regularly backed-up to in-house backup storage using Time Machine, will also be backed-up on a daily basis to TWO remote servers/cloud services. Also, every local Git repository will also have its copy on TWO remote Git repository servers, which will be updated (commit performed) also on a daily basis. All this may seem a bit paranoid, but I certainly don’t want to loose any important data again and in that regard I don’t mind some extra precautions. I assume I’ve learnt my lesson good.
Moreover, even the initial development of Springy 2.0 has started. As I mentioned in the previous blog post, this will be a good opportunity to some refactoring and redesigning of many things for which I haven’t had time before, as I was constantly tempted to add new features. I started from the ground-up, implementing faster and more robust automatic archive type and format recognition. Concrete results of this will be available very soon, in a form of Spotlight Importer plug-in which will enable you to index and search for files inside archives and disk images. This importer will provide significant improvements over existing ones on the market (including Apple’s Spotlight support for ZIP, TAR and CPIO archives in Snow Leopard), as it will support much wider range of archive types and formats (DMG and ISO images included), as well as all different archive specifics, such are for example Zip64 extensions, file encryption, multi-segmented archives, etc.
Soon after the Spotlight Importer plug-in, in parallel with continued development of Springy, I plan to release a QuickLook plug-in for quick preview of contents of wide range of archive and disk images types. There are a couple of these QL plug-ins in the market, but I think this one will be a bit special in the way it shows and browses archive contents and I hope many people will like it better over the existing ones.
With all these activities I hope to assure all current and future Springy users that I’m pretty serious about its development and intention to deliver version 2.0 somewhere in the spring – summer period next year. I’ll keep you all updated about my progress both here (with less frequent, but more descriptive and elaborative posts) and on Twitter account springyapp (more frequent, but short announcements lacking further details).
Dragan
Sad current state of development of Springy
Dragan posted Feb 5th 2010 at 8:00PM
The cause for this blog post is not a pleasant one. Not pleasant at all. Its main goal is to inform you about the near future of the Springy project, but also to admit that I didn’t seem to be quite serious about it, at least not when it comes to keeping its sources and resources safe enough.
About one and a half month ago I had burglars “visiting” my home on a nice December, Saturday evening, while I was out. Among other things, they stole two laptops, including my MBP, which was my primary development machine. But they also stole external hard disk hosting my Time Machine backup, as well as one pretty ugly and unattractive small PC box running FreeBSD, which served (among other things) as my Git repository server. I haven’t had the latest versions of Springy source code anywhere outside my home on any distant server. As a result of all this trouble, I don’t posses the source code for Springy any more! This also means that at the moment I cannot maintain it properly!
I didn’t rush to inform about this tragic incident as I wanted to see if there were any chances for the police to get my things back, or at least to plea to the burglars to somehow give my important data back. But now, after more than a month, I’m pretty sure there’s nothing that can be done about it. All Springy source code is gone for good.
I also spent some time browsing some older backups hopping I might find something useful. It appeared the latest Springy source code backup I had outside my home was that of a version 1.3.3, just before I switched to Leopard and started using Time Machine and Git as a version control system. As much as that old source code is useful, that’s far from enough to be able to continue smooth development of Springy; many features have been added meanwhile, and possibly even more things were completely redesigned, improved and overly changed. I may recover some of those by trying to remember what I did, browsing some old sketches made on paper and trying various reverse engineering techniques, but I don’t see it as a very useful and eventually successful process. Therefore my general conclusion is that the complete source code for the Springy project is irreversibly gone.
This whole story leaves the question about the future of Springy application. I have spent quite some time recently thinking about how to proceed and whether to do so at all. The idea of redoing everything and going through all known problems over again wasn’t very appealing at all. On the other hand, I think Springy is a very good archiving utility, with the right concept defined from the very beginning (everything must be done inside the application itself, no command line tools running inside NSTask and doing the real processing in the background, like so many other archiving utilities on Mac do), and decent implementation. Off course, it can always be better and the whole process of developing Springy was continuous improvements of the implementation, as my coding skills got hopefully better. Not to be neglected, the number of people who purchased it already and who probably use it on a daily basis for the tasks very important to them, they expect a decent support in case they encounter some problem, or find some bug. And only for those reasons, and for the fact I really enjoyed developing Springy, I decided to start it all over again and continue its development.
Unfortunately, the first results of that decision won’t be available soon. There are more reasons for that. The main one is that Springy was side job/hobby project from the very beginning. I have full-time job (unfortunately, it has nothing to do with Mac software development) and a private life to live, so the time I can dedicate to Springy is rather limited. It’s usually 12 – 22 hours per week, depending on a situation. This was also the reason the development of Springy so far wasn’t as fast as it could’ve been. I’d really like to transform Springy into my main job and dedicate full-time to it, but at the moment the revenue I get from it is far, far from what I need to pay my bills and still live a normal life. If at some point this situation changes, I’ll definitely consider my options, but I don’t see it happening in any near future.
The second main reason why the first results of new Springy development won’t become available any time soon is that I don’t want to just redo it from existing code (version 1.3.3) and add some more things on top of it. Even while developing/maintaining the current version, I’ve already wanted to change, redesign and refractor much of existing code. I learned a lot of things in the process, but Apple has also come up with a lot of new technologies in the meantime, and as I’ve tried them on some test projects, I’ve never had enough time to fully embrace them and incorporate into Springy code. While it will require probably less code to write, it doesn’t automatically mean less time as I really need to fully incorporate those technologies and since I haven’t done it before, I do expect to have some problems, questions and doubts over the correct way of doing things.
Taking all this into account, I don’t expect the new version of Springy to appear before mid 2011. Normally (with full-time dedication), it’d take a couple of months, but due to all the things explained above, the time frame expands considerably. Knowing this, it’s good to make a comment of the current status of Springy, as of version 1.6.1. The current implementation seems to be pretty good and stable, at least judging from the amount and kind of user complaints and bug reports. The most commonly reported problem is that Springy application sometimes crashes for some users while browsing archive and it can be traced down to icon preview generation. As that feature can be switched off very easily, I don’t see it as a really big problem (more about this you can read here and here). But there are some bugs which directly affect the functionality and they deserve a mention here:
1. This bug is related to SpringyCM contextual menu plug-in, for those users still running Leopard and Tiger. When a ZIP archive is extracted using SpringyCM, the plug-in doesn’t properly clean all of its traces afterwards (a handle to the archive file stays open). The consequence is that one cannot easily delete extracted archive by moving it to the trash and emptying the trash. The system will report that the file is still “in use”. Doing “Secure Empty Trash…” in FInder will however close the open handle and permanently delete a file. I’d rate this bug more as an annoyance, as it doesn’t really cripple the functionality of Springy in any way.
2. This one is more severe; ISO disk images can’t be created using Springy application, only using SpringyCM plug-in in Leopard and Tiger, and “Archive in ISO” service form the System Services menu in Snow Leopard. If one tries to select “ISO Image” from the pop-up button in save dialog in application, Springy will actually create an archive of type of the previous selection! This came up as a consequence of some NIB file editing I did in the last moments for version 1.6 and which I apparently didn’t test good enough. I know probably not many people use Springy to create ISO disk images, but still this bug is quite disturbing. Unfortunately, nothing can be done before the new version comes out. For those who need to create ISO images, please use “Archive in ISO” service form the System Services menu in Snow Leopard or SpringyCM plug-in in Leopard and Tiger.
3. It seems creating ZIP archive using “Archive in ZIP” service from the System Services menu (Snow Leopard only) is not completely reliable! For some reason, only sometimes, the preparation phase of archiving process is not done completely so some files are missing in the archiving phase. The consequence is the resulting archive may not contain all the files you’d expect it to. I really don’t have any clue why this happens. It was reported to me by a user and I managed to reproduce it myself. It doesn’t happen always and is very inconsistent in behaviour. For example, I’ve managed to correctly archive a bunch of files this way, than I did some other processing and then tried to repeat archiving of the same bunch of files again and it failed (some files were missing from the resulting archive). This can be very annoying, but I won’t be able to do anything about it before the new version comes out. If you find yourself in a similar situation and encounter this behaviour, please use Springy application directly (not “Archive in ZIP” service menu) to create ZIP archives. For other archive types, everything works as it should.
I really hope people will be able to live with these bugs, as I really can’t do anything about them in a short notice for all the reasons explained above.
I’ll post regularly over here about my progress with the new development of Springy. I’ve also created a new Twitter account springyapp (the name springy is already taken). While I’m not very much of a “twittering” person, I’ll try to use the account to update interested people about the progress more often, but in very short messages.
Needless to say, I’ve already started making full Time Machine backup to external hard drive again, but also I now make regular daily backups of selected folders to two remote servers, as well as keeping my Git repositories locally but also on two remote Git repository servers. It’s a pity I started appreciating all this precautions the hard way, once I lost all my source code, photos, music, movies, mails and many other very important documents and files. But it’s still better ever than never. I hope some people reading this may learn from my experience and prevent anything similar happening to them.
Dragan
