Seesaw
Problem
The 52N WPS currenty requires a client to constantly pull the status of a process. It would be nice if the user could be notified about the state of a process, most importantly when it is finished.
However, that is neither the task of the service, nor of the client (e.g.
Wps-js).
Solution
A third component, the seasaw, can be tasked to pull information from a resource at a defined interval, and if the response matches a certain pattern. The seasaw should be an independent resources from the WPS so that we only need one instance that can support many WPS.
User stories
- As a user I want to receive an Email with a link to the result of a WPS process once that it is finished so that I don't have to check myself all the time if it is done.
- As a user I want to be able to login to the Wobbler and see a list of all tasks that were submitted using my public identifier.
- As a user I want to see a list of all public tasks, i.e. all tasks that are not connected to a specific user.
- As a user I want to schedule a WPS process (having important side effects) to run at a defined interval and to be notified of the output so that I don't have to do the scheduling manually.
- As a user I want to schedule a WPS process to run once at a specified time so that I don't have to send the process at that time myself.
- As a user [..]
Features
- Response matching
- via regex
- via XPath
- via "strings contained"
- Actions for matched responses
- Send Email
- use WNS
- execute JS code (running in sandbox, Email API provided)
- Templates
- Specific actions for exceptional responses
- OAuth Login for backend (and eventually frontend)
- Persistent storage
- RESTful API
- POST a new task
- DELETE a task
- GET a task - get the status
Architecture
The Name
The service brings push and pull together, one thing happens and another thing is triggered, going up and down.