RESTful Tasker

[northox]

There's a need to have a RESTful tasker. Something that act as a transport layer between Flor and the real tasker. What I have in mind is to use Flack's API itself so it would be composed of two parts;

1. to manage workflows (e.g. create,list) and;
2. to act as a RESTful tasker - i.e. the Flack Tasker

This ticket is about the latter. I think by default Flack could provide a configurable tasker that would know at which URL (RESTful service) to push a received task. Then, a listener would accept the response from the RESTful client and push back the task to Flor. @jmettraux I would like your input on this.

n.b. At a latter time, we could expose the same thing but through a pull mechanism.

[jmettraux]

(linking to https://github.com/floraison/flack/issues/2 and https://github.com/floraison/flack/issues/4#issuecomment-285895247 for the sake of linking)

My initial answer would be: any developer sufficiently crazy/skilled to use flor can write a tasker that leverages a HTTP client. That's easy for web services that respond (almost) immediately (200), that's a bit different for services that would answer later (202 maybe). The developer would have to implement a polling mecha or tell the service about some "reentry" point (flack backed or not). Too many variations, let them implement it themselves.

But then I think about the simple cases where

sequence
  post 'https://example.org/message' exid: exid, text: 'hello from flor'
    # post some data to some endpoint
  get 'https://example.org/contests' to: f.contests
    # grabs some data from an endpoint

Already providing that would cover 80% of the cases, and give inspiration to fellow developers to build specific stuff they'd need, let's say until 95%...

Could we call it a "HttpTasker"? @northox what would go in the 80% for you? Is the snippet above inspiring? How would you write it?

[northox]

Well that would be cool/useful but for us, >80% requires a tasker that doesn't respond immediately thus blocking the workflow.

We could do with a pulling method like you describe (get) but it would required looping and sleeping (ugly). A push to a flack-listener would be better.

In #4 you said /message supports tasker reply message but I can only see handlers for launch and cancel. Is the intent to use this as a tasker listener?

[jmettraux]

We could do with a pulling method like you describe (get) but it would required looping and sleeping (ugly).

We could package the polling inside of the tasker

get 'https://example.com/x' count: 10 interval: '1m

A push to a flack-listener would be better.

you said /message supports tasker reply message but I can only see handlers for launch and cancel. Is the intent to use this as a tasker listener?

You are right, I have to implement it then so that the "push to a flack-listener" becomes a reality.

[jmettraux]

@northox OK if I use https://github.com/nahi/httpclient as HTTP client for flor? It's well maintained and dependence-free.

[northox]

Sounds good to me.