Synchronisation with Kasten, just to filesystems now

Sometimes it seems with faster and faster JavaScript-JIT-compilers and Gears/HTML5 the current software stacks, written in other languages, like e.g. Qt/KDE are going to be legacy. Google Docs & Co. show what is possible, with the browser as the generic adapter to the platform.
But the current software stacks are fighting back. Things like the openSUSE Build Service make it possible to have your code compiled and ready to be delivered for several platforms, run natively by the hardware you actually bought to do so, instead of having some resources abused for virtual layers. It just needs code which does not (over-)use platform-specific constructs. The expansion of Qt/KDE to more and more architectures is a fine example here what is possible.
Curious what will be next, perhaps Javascript programs using alternatively binary blocks of code compiled for popular hardware, given the OS has built-in access control? Things are merging.

With this in mind I congratulate the people from AbiWord on their new version 2.8, which not only improves the support for the open spec’ed on-disk format OpenDocument (.odt), but especially improves on the collaboration features which integrate the Web 2.0. That looks really great. My only nitpick is that this seems to be a non-FLOSS webservice. I just hope they find a good business model so that the software for the server can be shared, too. Others, like Inkscape or hopefully soon KOffice, might be interested in such a server system, too.

I also congratulate the people from Étoilé, who just have started to send objects over XMPP. This all sounds so promising.

Realtime collaboration and such data model synchronisation is something I hope Kasten, my WIP framework for composing programs, one day supports out of the box, too. From the very beginning this has been considered in the design, even if it is not yet too visible. And it still will take some time to get there.

There is other stuff to do first, like making Okteta work with very large files. This isn’t done yet, I am still working on it, but have hopes this feature will make it into the next release. Working with very large files means only loading the parts which are currently interesting (e.g. solved by memmapping the file). Currently Kasten, the framework Okteta is built on, only has support for the concept of loading document objects completely from the remote storage (like the filesystem on disk) to the working memory, done by subclasses of AbstractModelSynchronizer. There is a specialized subclass AbstractModelFileSystemSynchronizer, which takes care for the common stuff on dealing with the filesystem, including loading/storing to remote filesystems with KIO::NetAccess. So the/your document-specific subclass has just to implement the de- and encoding of the data from a QFile to the working data model.

Now, AbstractModelFileSystemSynchronizer was not really finished, so before adding a new construction site in Kasten for the partial-loading of files I want to finish the old one for the complete loading. E.g. there was no support for a property State of the remote storage. Thanks to KDirWatcher there is now some easily done initial one. Investigations are still needed how to make sure there is no race-condition where another process might break into writing to the file, reading the file’s timestamp of the own modification and starting to watch for changes again.
Also, KDirWatcher does not work for Kio-slaves. So files loaded from them are just marked to be in Unknown state. Besides, if the network connection is down, they are set to Unreachable. Solid::Networking serves this with just a few lines again 🙂

See in the screenshot for the two state symbols now in the Documents tool: the left icon shows the working data state (saved changes, unsaved changes), the right one the remote storage state. The yellow flag means Unknown, in case you wonder, and turns into the Network-disconnected icon if you disconnect from the network, like pulling the plug (looks impressive if you have several files loaded e.g. by sftp:// 😉 ). Well, seems I need to apply for some more icons from our icon heros.
Okteta Local and Remote Sync Status

Other changes in this area:

  • The action Revert is renamed to Reload. Revert will not do what the name says if the storage copy was modified since the loading of the document. Revert would rather mean undoing all changes, so that action semantic might rather appear in the Edit menu, for some quicker navigation through the change history.
  • The actions Reload and Save are only available if they are useful and usable. E.g. they are disabled if there are no known changes in both the working copy of the document data and the storage copy or the connection to the remote storage is lost.
  • Also new documents which are generated from random data or user input (like parameters) are set to modified, so closing them without adding any further content will still trigger the question if you really want to discard this perhaps unique data.

One thought on “Synchronisation with Kasten, just to filesystems now

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.