Migrating from 0.7 to 0.8

remoteStorage.js
1

For the past ~2 weeks me and ggrin have been working on remotestorage.js 0.8. It’s a partial rewrite and a few things have changed. They are listed in detail in the changelog: https://github.com/remotestorage/remotestorage.js/blob/develop/CHANGELOG.txt

NOTE: the widget has not fully been migrated to the latest version yet, so don’t worry if it doesn’t fully work for you. Still WIP.

This post is meant to describe some of the changes from an app developer’s perspective.

Getting 0.8:

0.8 is still in development. To get the current version, clone:

git://github.com/remotestorage/remotestorage.js

and checkout the develop branch. There you can run make build to get a built version of remotestorage.js. Run make minify after that if you’d like to have a minified version (though I don’t recommend doing that in development).

Changes to module definitions:

First of all: since the remoteStorage object is now an instance of RemoteStorage, modules are also declared globally.
So if you have been writing remoteStorage.defineModule(...) before, change it to RemoteStorage.defineModule(...) and you’re good to go. There is also a deprecation message to that effect.

Secondly the BaseClient has been changed a bit:

  • The use and release methods are deprecated in favor of cache(path) and cache(path), false).
  • Types/Schemas are now declared globally, scoped to the module they are defined in. This has a few implications:
    • You no longer need to declare the same type/schema on both the privateClient and the publicClient. Instead just declare it on one of them and both will be able to use it (because they have the same module name).
    • You can refer to schemas from other modules. For example you could do storeObject('contacts/vcard', '...', {...}) from any other module - given that the “contacts” module is included and declares the “vcard” type.
  • The BaseClient now brings a scope methods, which returns a new BaseClient, that operates on a subpath instead of on the module root.

Changes to configuring caching:

There are two major changes compared to 0.7:

  • There no longer is a “tree only” option. Either the entire data below a path is synchronized or nothing at all.
  • Caching can be configured on two levels: from a module, using the BaseClient#cache method, or from the app using the remoteStorage.caching interface.

Using caching is described in detail in this guide.

The “inspect” widget:

This is a little gimmick to help developers see what’s going on and debug caching problems. Run remoteStorage.inspect() in the console to display the inspector widget. It will show you the contents of
the connected remotestorage, the local cache and pending changes.

1 Like
2

This topic is now pinned. It will appear at the top of its category until it is either unpinned by a moderator, or the Clear Pin button is pressed.

3

not sure if we want to encourage that too much. wouldn’t it be better to link to contacts than to store them all over the place? also, it creates inter-module version dependencies

4

“the amount of data your app caches can have a significant impact on startup time of your app” (in the caching guide) - whether you cache or not, the startup time is always at most the time it takes to retrieve the data that is displayed “above the fold” at startup. Anything else is asynchronous.

also, we should mention (at least i hope this is the case), that outgoing changes are always cached while they are queueing. writing to a non-cached path should still only write locally return instantly, and then it would remove the local copy after push-out is complete. So not activating caching for a path leads to round-trip times on read, but the write-time will stay low.

5

also not sure if we should allow an app to activate caching on a certain path that it thinks the module uses for something. that creates a dependency that will break when you update the module to its next version (even if the module was careful not to change its api).

it would be better if the module exposes module-specific methods such as “cacheThumbnails()” or whatever.

6

also, to reset everything, just call remoteStorage.disconnect() from the console https://github.com/remotestorage/remotestorage.js/issues/367#issuecomment-21260150

7

0.8 has now been released, nobody should be using 0.7 anymore. see http://remotestorage.io/

8

Just for the record: I think it is a really bad decision to stop supporting 0.7 with the release of 0.8. Ideally always two versions are supported at the same time. You can’t expect developers to upgrade instantly.

9

In general I’d agree, but not before a 1.0. Things are moving fast and should break as much as possible so we can get to a stable 1.0 as fast as possible. Before we’re there I don’t believe it makes sense to spend time on supporting old pre-1.0 versions all the time.

10

I have upgraded Grouptabs/Gruppenkasse to 0.8. As the app is pretty simple in regard for data it was almost straight forward. I found out that AMD is not used any more. That is sad and also mentioned nowhere. In general there should be an upgrade guide. This thread and the very short changelog are not enough.

If you’re interested here’s the change to Grouptabs I did: https://github.com/xMartin/Gruppenkasse/commit/bb3c525bce7eb9df87249e63343055cdd2194d13
Note: I might rename this repo soon, so look for it in my account.

11

Just FYI: I removed the line about AMD from the add-to-app guide. Sorry about that and thanks for the hint.

12