Following on from this topic (especially my comments in my post there), I'd like to suggest some mechanism that would allow a project to inquire if it has a usable cloud connection.

The simplest form for this would just be a boolean sensor block, something like this:

connected to cloud :: sensing boolean

I can imagine that Scratchers would likely place such a block into a tight loop, so it would be desirable, in terms of implementation, for it to NOT contact the cloud server every time the Scratch execution engine reaches it. Instead, some kind of regular, but not too frequent, polling mechanism, perhaps? (A bit like cloud variable http fallback?) And only if the project contains the block.

An alternative, even more generally useful, may be to provide a cloud server time-stamp reporter:

cloud timestamp :: sensing reporter

This might report an integer that could be, say, the number of seconds since the start of year 2000, according to the cloud server (i.e. in its time zone, or maybe UT - doesn't really matter, as long as it's fixed). It's a little like a really global cloud variable (across all projects and all users).

Such a timer would not only provide a mechanism to check for cloud disconnect (if the timestamp has the same value after a few seconds, then it's likely there is no longer cloud connection), but also a multitude of useful new possibilities for cloud-enabled projects (how long since anyone last ran the project; how long since a particular player last updated their cloud values in a multiplayer game, etc…)

Again, in terms of implementation, it would only poll (or be pushed from) the cloud server every so often, and would not poll at all if the project doesn't contain the block.

Thoughts?

UPDATE: see most recent list of implementation possibilities: http://scratch.mit.edu.ezproxyberklee.flo.org/discuss/post/546966/

Support for both, the second would have more uses as you said but the first would also be helpful if you needed a quick way to test connection.
Maybe (global seconds since 2000) would fit in better with the name of the current (days since 2000) block.

TheLogFather wrote:

Following on from this topic (especially my comments in my post there), I'd like to suggest some mechanism that would allow a project to inquire if it has a usable cloud connection.

The simplest form for this would just be a boolean sensor block, something like this:

connected to cloud :: sensing reporter

I can imagine that Scratchers would likely place such a block into a tight loop, so it would be desirable, in terms of implementation for it to NOT contact the cloud server every time the Scratch execution engine reaches it. Instead, some kind of regular, but not too frequent, polling mechanism, perhaps? (A bit like cloud variable http fallback?) And only if the project contains the block.

An alternative, and even more generally useful method, may be to provide a cloud server time-stamp reporter:

cloud timestamp :: sensing reporter

This might report an integer that could be, say, the number of seconds since the start of year 2000, according to the cloud server (i.e. in its time zone, or maybe UT - doesn't really matter, as long as it's fixed). It's a little like a really global cloud variable (across all projects and all users).

Such a timer would not only provide a mechanism to check for cloud disconnect (if the timestamp has the same value after a few seconds, then it's likely there is no longer cloud connection), but also a multitude of useful new possibilities for cloud-enabled projects (how long since anyone last ran the project; how long since a particular player last updated their cloud values in a multiplayer game, etc…)

Again, in terms of implementation, it would only poll the cloud server every so often, and would not poll at all if the project doesn't contain the block.

Thoughts?

That still allows for a test and then an attempt to set which silently fails if the cloud goes away after the test but before the setting. We need a solution that is an atomic set & test. Or a check to see if the cloud var in the browser is live or cached?

G

Support for number 2.

gtoal wrote:

That still allows for a test and then an attempt to set which silently fails if the cloud goes away after the test but before the setting. We need a solution that is an atomic set & test. Or a check to see if the cloud var in the browser is live or cached?

Ideally, yes - but I don't see a fool-proof way around this kind of thing without a total reimplementation of cloudvars (which is not likely to happen). I only see that it's possible to reduce the issues, make them somewhat less likely, by adding things like this. You can do the cloud connection test at various points *after* you've set the cloudvar, and if it fails then at least provide some kind of warning to the user.

I mean, for example, in terms of cloudvars themselves, there is currently no way to know what will happen if two users update the same cloudvar at very nearly the same time. If a user sets a new value for a cloudvar, and then receives a different new value for it very soon after, you then can't tell, without doing further checks, waiting for a new value yet again, whether that ‘new’ value was sent to you by the server *before* it received the value you just sent (i.e. your value is really the newest), or if the server is about to now send you your even newer value, as just set by yourself (in which case the value you currently have is out-of-order, since it has appeared to replace your own value which is really the latest the cloud server has).

And if your own value was not the latest, so the other user did get a value to the cloud server after yours got there, it's quite likely they (and everyone else) would never get a chance to see your value, hence meaning any values in there relevant to your player are ‘lost forever’ (because the other user never saw them, and would still have kept your older values in there).

And don't even get me started on what happens if you've fallen back to http polling…

When it comes to cloudvars, there are so many uncertainties about what's really happening. You can only really take a look at what you've done, what you've got, and then make numerous guesses to try to vaguely make some sense of it…
I think adding a block like one of above would be a quick way to make *much* more sense of it (even if it doesn't eliminate the guessing entirely).

but isn't it a given that a project is connected to cloud upon loading? I support the second block, but maybe it should read

<time since [cloud var v] updated ::sensing> //returns the time elapsed in seconds since the last update was made

I think an asynchronous event would be preferable something like

when cloudvar updated :: hat  events

Zro716 wrote:

but isn't it a given that a project is connected to cloud upon loading?

Assuming the user is a Scratcher, and the user's browser has successfully contacted the cloud server, and the cloud server is working, yes. (See this project, for a simple cloud connection test.)

But one of the issues is knowing that you're still connected, and that your changes are actually getting through. For example, as mentioned in the original thread, if you start up a second instance of the project, that second one ‘takes over’ (even without running it), and you silently lose everything changed by the first one. (In particular, the first project can't tell at all that its changes are now failing to actually get noticed by the cloud server.)

Zro716 wrote:

I support the second block, but maybe it should read

<time since [cloud var v] updated ::sensing> //returns the time elapsed in seconds since the last update was made

I presume the answer would have to be from the cloud server's point of view, rather than from the project's (since it would otherwise defeat the purpose).

I suspect there would be some implementation issues with that, but it would be very useful if it could be done…

drmcw wrote:

I think an asynchronous event would be preferable something like

when cloudvar updated :: hat  events

I don't see how that helps with the question of knowing if your connection to the cloud is still viable…?
One of the fundamental problems is that being the only user running a project looks identical, from within the project, to being disconnected from the cloud. The only way to tell the difference (apart from sniffing your connection with something like tcpdump/wireshark/netsniff) is to manually reload the project (or the cloud log) and see if the new values actually made it to the cloud server.

TheLogFather wrote:

drmcw wrote:

I think an asynchronous event would be preferable something like

when cloudvar updated :: hat  events

I don't see how that helps with the question of knowing if your connection to the cloud is working…?
One of the fundamental problems is that being the only user running a project looks identical, from within the project, to being disconnected from the cloud. The only way to tell the difference (apart from sniffing your connection with something like tcpdump/wireshark/netsniff) is to manually reload the project (or the cloud log) and see if the new values actually made it to the cloud server.

The event would only be triggered by a server update. You could then set a timer after a cloudvar change and If there was no update after a few seconds then you'd have an idea that an important write had failed.

drmcw wrote:

The event would only be triggered by a server update. You could then set a timer after a cloudvar change and If there was no update after a few seconds then you'd have an idea that an important write had failed.

Ah, I see… yes, interesting idea.

At the moment I suspect (but haven't checked) that the cloud server doesn't push anything to you about your own changes to a cloudvar. I guess it might be possible to change that behaviour, in which case an event like that could do the job…


OK, I'll add that to the list of implementation possibilities…

connected to cloud :: sensing boolean // simple boolean
cloud timestamp :: sensing reporter // a 'pushed/polled' integer with seconds since start of year 2000 (or something similar)
time since [cloudvar v] changed :: sensing reporter // value must be kept updated by cloud server itself; suggested by Zro716
when [cloudvar v] changes :: events hat // only triggered by cloud server; suggested by drmcw

TheLogFather wrote:

drmcw wrote:

The event would only be triggered by a server update. You could then set a timer after a cloudvar change and If there was no update after a few seconds then you'd have an idea that an important write had failed.

Ah, I see… yes, interesting idea.

At the moment I suspect (but haven't checked) that the cloud server doesn't push anything to you about your own changes to a cloudvar. I guess it might be possible to change that behaviour, in which case an event like that could do the job…


OK, I'll add that to the list of implementation possibilities…

connected to cloud :: sensing reporter // simple boolean
cloud timestamp :: sensing reporter // a 'pushed/polled' integer with seconds since start of year 2000 (or something similar)
time since [cloudvar v] changed :: sensing reporter // value must be kept updated by cloud server itself; suggested by Zro716
when [cloudvar v] changes :: events hat // only triggered by cloud server; suggested by drmcw

Support for all of these! I'm making a cloud multiplayer game right now (from scratch; I don't believe in using other peoples' Scratch code) and it's really annoying how I have to account for all sorts of potential problems (especially lag and network connectivity).

I support Zro16's block.

Support everything.

I have an idea.

if [connected to cloud? v] then
broadcast [ConnectedtoCloud v]
else
broadcast [NotConnected v]
end

Possibly, that block could come into the pile someday… Or, alternatively,

wait until [connectedToCloud v]

Or even possibly,

add [connected to cloud v] to [cloudDetector  v]

Possibly more things for a list.

+1!

Support for both!

I like the timestamp one :3

Wait, even if no one else is writing to the cloud var, what you write can disappear? This topic is a year old, so I'm wondering if this was fixed, or do changes to cloud variables still silently disappear, cuz griffpatch's multiplayer projects dont appear to suffer…

I support all of these!

No support, Sorry.