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.
Dragan
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
