Yesterday, ownCloud Client 1.2.0 was released. You can get it from here. We worked on this since end of november last year, you might have seen my other blogs about the beta versions we had for this release.
What is interesting about the release from a more technical point of view? Here are a couple of examples.
One of the things which often was complained about was the performance of the client. Performance is a very broad term, so we have to examine the details: Many people felt like its a performance problem that former clients polled the local file system for changes on the MacOSX and Windows platform. That was recommended from other projects which have experience with going through large file collections. QFileSystemWatcher seemed not to be designed for this usecase.
Polling was ok for desktop computers with up-to-date hardware, but on devices running from batteries this was a energy drain. Good that we could fix that with 1.2.0 using native implementation of change detectors on Windows and MacOSX. They detect changes within a file system tree. If a change is detected, a sync run is started. But note, this is only for local file systems. Detection of changes on the server is a different story which has to be told as well.
Another performance problem was within the file upload which is done by a HTTP PUT request. Month ago (pretty after my start at ownCloud) I implemented it using a tmp file in between. That means, the source file was copied to a tmp file, and from that it was processed to the request body. Improvement was needed and we changed the code to directly read from the file descriptor of the opened source file.
Another thing that was improved with 1.2.0 is the error reporting to the user. Former versions of the client sometimes provided error messages which were not really accurately describing the problem. The reason for that was that csync uses errnos (yes, the ones from errno.h) to name errors as csync maps everything to a POSIX file interface. That surely works as long as you’re on a kind of file system. But it’s hard to map HTTP communication problems onto that. So we decided to add our own “custom” errnos and enhance the whole idea to use these to describe problems. That works more accurate now.
The next things on the list are for example a more convenient setup dialog for the client. Also we will get away from the kind of hard coded target file name on the cloud. A better network recognition will also be next as well as better handling of big files. And more…
Thanks a lot to all who helped to get 1.2.0 finished! It is big fun to work in such a great community :-)