The basic use of MQTT in Snap! lets you send a message to a broker on a particular topic and then that broker will forward the message onto other programs running on other computers subscribing to the same topic on the same broker.
The converse is true, someone can send a message to a broker on a particular topic from another program (libraries are available for all the usual programming languages) and Snap! can subscribe to that topic and receive a message every time the other computer/program sends one out
FAQ - Can I store a message on a broker at say 3pm, and someone connect to the same broker and topic at 4pm and retrieve the message?
USUAL WARNING - DO NOT USE MQTT TO SET UP A CHAT SERVICE!!! Also, the free public brokers have no guarantee of service and may delete any messages and topics at anytime. They may also, have topic storage and rate limits on them and they may IP ban you if you exceed these
Do do this, you need to set the second option of your published message to true
e.g.
Any message published using this option, will be stored on the broker (it is termed a retained message) and as long as no other messages are published to the broker on that topic (or the broker is reset/cleared by it's system administrators) the message will remain on the broker indefinitely
To erase a message retained in this manner, you just need to send an empty payload on the same topic
e.g.
Ugh, the options have an undocumented fixed order? What a kludge. Sooner or later I'm going to convince Jens that we need a category of 0/0/1 (min, default, max number of slots) multiple inputs with labels, so it could be "options ︎ ︎ ︎" for however many options there are, and if you click the second one it turns into "retain: <● >" (that's ascii-art for a Boolean slot) and the same for the others. Or, I guess even better, a multiple input group consisting of a menu of option names and an Any slot, so you could choose "retain" from the menu and drag in a True, so you don't have to remember which arrowhead to click. Or, if all the options are Boolean, we could just have a multiple-slot menu with the names, and turn on the ones the user chooses.
Sorry, what I meant was, not self-documenting in the block itself.
One of the reasons why I never learned Smalltalk was that the first example of creating a method was something like
method foo [bar, baz]
(I'm sure I have the details all wrong) and when I finally got my tongue rolled back into my mouth I had lost my motivation.
I think I was better able to tolerate such interfaces in my youth. There are things a little like that in Berkeley Logo, although the fields are closely related to each other, and the same set of options occur in a bunch of different contexts so you only have to learn it once.
The input is called a "contents list" and the three pieces are in order of common use, so you can say ERASE [[proc1 proc2 ...]] and it's only if you have only property lists to erase (or save or print out etc.) that you need [ [plist1 plist2 ...]]. (And we also accept ERASE [proc1 proc2 ...] not inside an outer list wrapper, or ERASE "proc1 if there's only one procedure involved.)
︎ 