What are remotestorage.js /public/ requests?

[Marcin Ignac]

Hi,

I'm using remotestorage.js 0.7.2 and restore on the backend/nodejs side. Whenever remotestorage tries to sync it makes request to  http://HOST/USER/public/MODULE/ and bounces back with 404 the proper and working url to get data is http://HOST/storage/USER/MODEL that is used on  [GETPUTDELETE].

Anybody knows what are these /public/ request?

[Michiel B. de Jong]

yes, off the top of my head, this is the code you need to use to stop
them from happening:

http://community.remotestorage.io/t/what-are-remotestorage-js-public-requests/44

[Marcin Ignac]

yes, off the top of my head, this is the code you need to use to stop
them from happening:

http://community.remotestorage.io/t/what-are-remotestorage-js-public-requests/44

Great! It worked.

Now after I discovered I also have to remoteStorage.schedule.enable(); manually, everything works prefect.

Thanks 

[Michiel B. de Jong]

On 2013-06-05 11:03, Marcin Ignac wrote:
> Now after I discovered I also have to
> remoteStorage.schedule.enable();
> manually, everything works prefect.

ah! yes sorry about that, you indeed have to do that with the 0.7.2
library.

it's a bug, and will be fixed in 0.7.3, which is probably coming out
before the weekend:
https://github.com/remotestorage/remotestorage.js/issues/325
http://community.remotestorage.io/t/regular-release-schedule/37/5

sorry for all the pain you had to go through! Out of interest, what app
are you building? Looking forward to seeing it in action! Let us know if
you run into any more questions.

Cheers,
Michiel

[Marcin Ignac]

Hi,

I'm working on personal finance app but more towards Quantified Self + Data Viz area than serious Banking. I basically log everything I buy daily and try to make predictions based on patters. Unstable life of a freelancer requires me to be a bit more aware of what's happening. I love remoteStorage because of offline capability and I got first html prototype up and running in 2 days which is awesome. I store each transaction as a separate item / document so I have some concerns in the future e.g. what hen I have 500+ items. Or what if I exceed localStorage limit in my browser?

[pir...@gmail.com]

What about IndexedDB? Maybe is more useful for an app like this, and also doesn't have space limits... Regarding RemoteStorage, you would do dumps of the database :-)

--
 
---
You received this message because you are subscribed to the Google Groups "Unhosted Web Apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to unhosted+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Sebastian Kippe]

IndexedDB support is still an important open issue for remoteStorage.js. At the moment you would indeed run into errors, that aren't even handled by the library.

I hope we have something ready soon!

[pir...@gmail.com]

Oh, do you plan to integrate IndexedDB inside remoteStorage? Something like remoteIndexedDB?' That would be cool :-) Please ask me any question do you have, I have been fighting with the IndexedDB specification lately... :-D

[Sebastian Kippe]

remoteStorage.js currently uses localStorage for caching data locally. That's just not viable for sufficiently large amounts of data, so we must switch to IndexedDB at some point (including a WebSQL shim for mobile browsers that don't support IndexedDB yet).

nilclass started working on it a while ago, but I don't know the current status. Maybe he can tell us more about this?

[Niklas Cathor]

Yes I can.

The primary problem with the indexedDB backend is that indexedDB transactions are committed implicitly, unless a new operation is started directly from the success callback of the previous operation in that transaction. Due to the way remoteStorage's storage-backend interface is designed, that doesn't happen though - but instead sometimes the next operation happens asynchronously.

I currently see two alternatives to move forward:

1) Implement custom transactions on top of the indexedDB API - that sounds like the simplest to me, but is horribly slow (There is a start of this implementation here: https://github.com/remotestorage/remotestorage.js/tree/feature/indexed-db-backend)

2) Rewrite the "store" to implement all operations that need to be atomic in a way that they don't have asynchronous calls in between.

After experimenting with (1) for a while, I currently tend to do (2). Also I'm very much open to new ideas.

[Sebastian Kippe]

Let's keep this mailing list free of implementation detail discussions. I added your reply to my question on the remoteStorage forums: http://community.remotestorage.io/t/indexeddb-support/45/2

Cheers

Basti