no data fetched in on windows?

[silverbucket]

I don't know if I'm missing something huge here, but booted into windows for the first time in a year, and tried out some remoteStorage apps, none of the data is being fetched. I just get immediately resolved promises with undefined data:

remoteStorage.rss.getAll().then(function(data) {console.log('DATA:',data);},function(err){console.log('ERR:', err);});
Object {then: function, fulfill: function, reject: function}
DATA: undefined

This happens with both dogfeed and litewrite (the only two i tested)

It seems afterward, there are several http GETs, but the promises are being return immediately, so any data from those gets goes nowhere.

This was with chrome, firefox isn't installed on the machine at the moment, but if you think it's a browser thing i can install it tomorrow.

[michielbdejong]

i would say this is expected, and should happen in any browser/OS combination.

if you call getAll() on the rss module, then it will return what is currently in the cache, and return that immediately. getting data from a module is unrelated from the "asynchronous synchronization" process fetching data from remote.

if you want to use remotestorage.js just for directly accessing remote (as a "wire client"), then use the -nocache build.

[raucao]

Hey, I have this same problem in an app I'm developing and it's highly annoying from both a developer and a user standpoint. When I connect an app to a storage, I'd expect that all data is synced immediately, if caching is turned on. Instead, it's synced some 5 to 10 seconds after connecting to the storage.

For example, I'm working on a bookmarking app, and it means when you connect to your storage in a new browser or on a new device, you have to wait 10 seconds until you see any of your bookmarks. And as a developer, you have to listen to the change event and can't use a convenient getAll, even if you don't want to implement background-updating functionality at all.

[silverbucket]

Isn't the whole point of a cache to be filled when empty? I don't understand why the behavior of remotestorage keeps changing in regards to this. If I do a getAll, and the cache is empty, remotestorage should fetch the data. That's what the promises are for afterall...

[raucao]

Isn't the whole point of a cache to be filled when empty?

Yes, that's what I thought as well. It's only a local cache, so if the cache isn't up-to-date with the remote storage, it should be updated before delivering data, when being asked for all data in a path. No?

[michielbdejong]

you always have to implement the onChange event anyway. but i can see how there are times where you want to know if a certain folder is "up to date", which could mean any of:

• not connected (just a local session)
• incoming changes are known to exist, but caching is set to "off"
• sending outgoing changes (during initial sync)
• sending outgoing changes (during normal use)
• outgoing change are known to exist, but network is offline

or "not up to date", which could mean any of:

• receiving an incoming change (during initial sync)
• receiving an incoming change (during normal use)

it would make sense to display a list view as "up to date"/"not up to date", and i guess that's currently not really possible.

[silverbucket]

First of all, the getAll() function is always returning undefined, even after I wait 10 minutes, it's still returning nothing. (and yes, there's data there).

Second, the purpose of a cache is to quickly provide results to queries which would yield the same information. If the server has updated data, the cache should detect this and fetch updated data.

[raucao]

it would make sense to display a list view as "up to date"/"not up to date", and i guess that's currently not really possible.

No, I think that's not a solution to the problem. And no, one doesn't absolutely have to implement the change event, if it's not important for the app to display incoming changes until the next usage or context switch.

the purpose of a cache is to quickly provide results to queries which would yield the same information. If the server has updated date, the cache should detect this and fetch updated data.

That's exactly how I see it as well.

[raucao]

To clarify: I do see how it would be nice to only use change events and display some kind of "currently syncing" UI element until all changes have been synced, but I don't think devs should be forced to do that, if the use case doesn't fit. Also, I think it's a different case for initial sync than for later ones, especially if it takes a couple of seconds until the initial one starts.

[michielbdejong]

there are two issues:

• get functions shouldn't return the promise if sync is busy (created https://github.com/remotestorage/remotestorage.js/issues/422 about this)
• fetching data not working on Windows (this bug, now assigned to @silverbucket who will test this again, and dig into this further)

[michielbdejong]

works for me, I just tried it.

[raucao]

That is one uninformative comment, my friend. :)

• What works for you?
• You tried what?

[silverbucket]

Yeah, please leave a record here so that I or someone, even if they may not have the time to have a look at this bug right now, can revisit and find an informative synopsis of what you've done. Otherwise there's no way to know whether to address a misunderstanding, concur, or open a new bug.

[silverbucket]

Also, I might add that I don't think it makes sense to close this bug until the "root problem" (#422) is resolved since they were related, and testing this without the other being fixed could lead to ambiguity.

[michielbdejong]

this bug was about "fetching data not working on Windows" as reported by @silverbucket "I don't know if I'm missing something huge here, but booted into windows for the first time in a year, and tried out some remoteStorage apps, none of the data is being fetched."

i tried out litewrite in IE and FF on Windows 8, and data was being fetched. also, in the three months since this bug was first reported, it was never ever reproduced by anybody. that's why i'm closing this bug as "works for me".

as for #422 that bug is still open, so please post further comments there, not on this Windows-specific one.

[silverbucket]

Sebastian reported having the same issues. If the problem was that, on the windows machines, none of the data was synced and the getAll() calls were resolving their promises based on the non-existence of the local cache (which is incorrect) rather than the fact that it needs to pull the data from the server first, then I would agree that this was probably never an actual bug, but I'm not sure if that was the case.

Did you try the example snippet I pasted in the original post?

[silverbucket]

(by never an actual bug I mean, #422 would cover that issue)

[raucao]

422 would cover it if sync actually starts immediately after connecting.

[silverbucket]

Yeah I agree, thanks for the clarification @michielbdejong

[ggrin]

but afaik the first sync-cycle starts when the ready event is fired which happens after each connect

src/sync.js line 336

but when the caching gets enabled after remotestorage connects then this would mean that sync for those pathes starts after the next sync cycle

[raucao]

Just a hint: you can get a URL for specific lines of code by clicking on the line number. Like so:

https://github.com/remotestorage/remotestorage.js/blob/master/src/sync.js#L336