Has anyone set up anything like Javascript style promises for webhook calls in their device FW? I’m looking into the std::promise/future/async and wondering if that would be a good approach or if there’s maybe a simpler way to handle it.
For example, a device could make a webhook call to get the latest forecast, and the server could return the result, an error or it could timeout if the server is down. Maybe it could look like this:
void sucessFunction(const char* event, const char* data); // function to run on success
void errorFunction(const char* event, const char* data); // function to run on error
void timeoutFunction(); // function to run on timeout
void sendWebhookFunction(); // function to create the webhook call (needs to call Particle.publish);
MyPromise getForecast(*successFunction, *errorFunction, *timeoutFunction); // create promise object
getForecast.createSubscribe("myResonseTopic"); //creates a Particle.subscribe that listens for the response
getForecast.promise(*sendWebhookFunction); // send the webhook
It’s possible, but there are a few things that make this tricky in practice.
Blocking the loop thread is generally bad practice, thus making blocking promises not a great programming model.
And threads on Particle sort of work but there are a lot of caveats to that, so standard async with a thread pool is also a bit of a problem.
They’re not insurmountable problems, but tricky to get right.
In general, I would lean toward a callback approach (probably using lambdas) instead of trying to make futures work.
I should point out that parts of system firmware do use promises, mainly to get data between the system thread and the user thread (loop), such as publish completion status in 0.7.0 and later. They make sense in certain situations like that, but I’m not convinced it’s a good general programming model for Particle devices at this time.
I’m thinking about working on a library and looking at a callback approach as well. It pushes the edges of my cpp knowledge passing around class member functions.
Another hangup is interfacing with Particle.subscribe() and that .unsubscribe() removes ALL subscribers.
Agreed, maybe you could chime in on this long pending issue I opened 1.5 years ago 
https://github.com/particle-iot/firmware/issues/1123
1 Like
Versus just ignoring the event in your handler?
I’m guessing that it is more of an issue on an electron.
The point is that I’m not only not interested in the event anymore but I want to set up a new one with different filter but only have the option to setup max four handlers.
So dumping one and setting up a new one would always require to dump and setup the three still remaining ones anew, potentially losing any events triggered during that timespan.
This issue is independent of platform - when the use-case calls for it it doesn’t matter what platform its running on.
I’m aware of the workaround to setup one unfiltered subscription and do all the filtering in code - but that’s not the point.
I didn’t mean to get your dander up.
I guess I’ve not yet come across a need for a fifth dimension of event generators to which I need to respond.
I’m managing subscribe() at peer levels:
Self
Group
Community
Universe
But I can see your need to change Group or Conmunity, for example.
1 Like
What made you think your post did?
All's good 
1 Like