Slow progress of development of Springy 2.0
Dragan, posted Nov 21st 2010 at 3:00PM
It’s been quite a while since my last post about the progress of development of Springy 2.0. I was quiet for two main reasons: the first one is not so good; there wasn’t much going on with the development. The second one is much better; there were some activities which would change my professional path in the near future, and that also means more time and devotion to Springy.
The development didn’t move much beyond robust automatic archive recognition and developing the new model to represent archives. It actually stuck in 7-ZIP development. I implemented archive models (including methods for opening, extracting and adding files) for all archive types Springy currently supports; ZIP, TAR, PAX, CPIO (including all common compression methods, such are GZIP, BZIP2, LZMA, LZ, Unix Compress and all that with support for multiple stacked compressions), RAR, DMG, ISO, SIT/SITX… And then I started with 7-ZIP. It turned out to be much more challenging that I anticipated. You can read some of the reasons in this blog post. To make a long story short, the modifications I made to original p7zip code, in order to build a proper library and link against, are really tweaks to the code to make it work for my purposes. I released that code in Springy 1.6 (which brought read-only 7-ZIP support), but it is ugly, unstructured and really made just to get the work done. I included it in Springy 1.6 just because the request for 7-ZIP support was strong, but it’s hardly maintainable and I don’t want to use it any more. So I started playing with reconstructing 7-ZIP format on my own, making a code around it, and it certainly took quite some time.
While doing that, Steve Gehrman of CocoaTech, the author of Path Finder which many of you probably know, needed some help to speed up the development of upcoming Path Finder 6. So he asked me to help. This was a great opportunity for me to work with a proven Mac developer, so I decided to step in. I was busy working on Path Finder in my spare time, doing it as a second job (I still have full-time daily job, not related to Mac development). It’s been successful so far, both Steve and me are satisfied with our collaboration. Of course, all this left development of Springy in certain limbo. I haven’t worked on Springy ever since I started working on Path Finder (sometime in June). Path FInder and my struggle with 7-ZIP support resulted in no visible progress of Springy development.
But this will change soon. If everything works out the way I planned, I should completely switch to full-time Mac/iOS development from February next year. Most of it will be devoted to Path Finder, but a significant portion of time will go into Springy as well. This will hopefully greatly increase its development pace.
In the meantime, Springy seems to work just fine. The sale, while still not being big enough to be the main source of income, is quite steady on a monthly basis. And while the user base steadily increases, I really don’t receive bug or problem reports. The version 1.6.1 seems to be very polished. The only exception is mysterious “No document could be created” issue, more of which can you read here and here. It seems to be related to some strange corruption of user’s LaunchService database that I still couldn’t manage to reproduce. It was reported by 5 users so far. It was apparently user-domain and not system-domain related, which means Springy starts failing with the message “No document could be created” for one user in the system, but for other users it works just fine(?!?). Hopefully, deleting the problematic user, creating the new one with the same name and restoring all users data from the backup (you do make regular backups, do you?) resolves this problem. At the moment I don’t have any smarter suggestion on how to solve this rather strange issue.
On a positive side, Springy seems to becoming quite popular with ePub e-books publishers, as it enables quick and streamlined editing of files already embedded in a ePub file format (which is actually just a ZIP file with a particular directory structure). I suppose the reason for this popularity was this document, published on Adobe blogs site. So, one of the goal for Springy 2.0 will be more ePub file format awareness.
So stay tuned. While the progress is very slow, I hope the final result will be worth waiting.