Poll-based vs message-based blocks

I'm sorry I have no idea which category to put this in. But I'm wondering something -- in some libraries, e.g. the MQTT library, when the user wants something to happen when a message is received, they provide a ring that runs whenever a message is received, like this:

image

It makes sense if you know how the JavaScript code works internally. But I've always found this to be strange, somehow... It doesn't seem that this type of pattern occurs in other built-in/library blocks. For example, the ask block also outputs a deferred output, but it does it by waiting instead of calling a given command in the future. And it's probably just that way in JavaScript since threads can't yield (unless you use a generator function)

So I was wondering if it'd better if message data was instead read something like this, where it waits for a message and returns it. I think this is called polling.

image

I feel like that would make more sense. What do you think? Is poll-based or message-based better?

I'd say #advanced-topics

edit - ignore this - I was just waking up :slight_smile:
I think the difference between the MQTT subscribe block and the ask block is that only one ask block can be in use at any one time (e.g two sprites can't ask questions at the same time)

Whereas several subscribe blocks can be waiting for to receive messages completely independently of each other

But having said that, let me play around and see if I can make something simple like you suggest for simple use cases.

I've woken up properly now :slight_smile: and come up with this first draft concept of using an upvar

image

Username=cymplecy&ProjectName=waitMQTT

[edit - this script shows that its actually waiting
You'll notice that the reported timestamp is only changing every 5000 milliseconds, which is how often I'm publishing the UTC datetime ]
image

FYI MQTT extension development

The MQTT extension blocks are being updated for Snap! V8 and the new library is available on a GitLab fork - just in case anyone comes across a bug or a missing feature - that is the one being actively developed by myself and Xavier Pi (the original author of the MQTT blocks)

Snap! Build Your Own Blocks

Polling would be using a FOREVER IF block to test for a returned value once per display cycle.

Your notation, I think, is agnostic as to how the waiting is done. It could be implemented (whether in Snap! code or in JS) using either a FOREVER IF or a callback as in the current library. Typically callbacks are more efficient because they match what the operating system typically gives you.

I like your notation precisely for that reason -- it abstracts away the implementation mechanism.

However, the elegance of your notation depends on the fact that the message reports only one value. Is that always the case? If not, your block would have to be a command with upvars to hold the message's return values, followed by an imperative script to make sense of them, or else it'd have to report a list, which the surrounding code would have to tear apart, so it'd be equally ugly and non-functional.

This is sort of the same problem that object oriented programming has when a message has more than one input, and you only get to dispatch on the type of one of them. (So instead of real OOP people use generic functions to dispatch on the types of all the inputs.)

Using the extra subscribe block, it seems to cope with the data rate from joecooldoo's Pen Online project :slight_smile:
It's not 100% perfect but I think it would be good enough for a lot of projects

image

Username=cymplecy&ProjectName=PenOnlineUsingWait - original project by joecooldoo

The question is - do we just make the block return the message payload or the received message topic as well?

Background info on MQTT subscriptions

You can subscribe to all messages on a topic by using a wildcard such as name/#. When a message is received by a subscriber to a wildcard topic, then the received topic can be used to determine which actual topic had a message published to it.

So, if the block doesn't supply the received topic, then it would be restricted in how it dealt with wildcard subscriptions

And by the time I've written all this out, I've talked myself into deciding that is should have a received topic upvar as well

So V2 of the block
image

Username=cymplecy&ProjectName=waitMQTTV2

Just an FYI: My project uses a queuing system so that drawings are accurate to what the primary user initially drew.

Did some repeatable testing using this to simulate soneone drawing a zig-zag pattern

Using just a monitoring script
image

it should log 24 messages but once the wait send interval got down to 0.05 secs, it started not recording some of the messages

It was fine at wait interval of 0.1

So, this approach isn't actually good enough for joecooldoo's project as mouse movements can be sent much quicker than 10/sec

So at the moment, I'm thinking not to add it into the MQTT library extension

You should post this on #advanced-topics or #advanced-topics:advanced-help-with-snap

Sorry for the late reply but in my humble opinion I'm unsure about using upvars. It is definitely an interesting idea but it's not as... expressive? I don't know how to explain it. (It also reminds me of a convention in C programming, where the programmer declares an uninitialized variable, and passes in the address of that variable to a function which sets the variable.)

I'll have a play at seeing if I can hide the messages until they are asked for in the forever loop.