Skip to content

Incremental retrieval of plans as they are discovered #39

@jan-dolejsi

Description

@jan-dolejsi

Planners that support multiple plans are penalized by this interface in the eyes of the end user. The planner may have come up with one or multiple plans, but the end-user still stares at a blanc screen.

Rather than the state transition from PENDING to ok, we should support QUEUEING -> INITIALIZING -> SEARCHING_FOR_INITIAL_PLAN -> SEARCHING_FOR_INITIAL_PLAN -> STOPPED -> HTTP404 (when the plans are removed).

The first endpoint post request should return the session/run ID:

POST /package/xyz/solve

{
  "status": "QUEUEING",
  "id": "qwer-qwer-qwer-qwer"
}

GET /package/xyz/solve/qwer-qwer-qwer-qwer

{
  "status": "SEARCHING...",
  "plansFound": 2
}

GET /package/xyz/solve/qwer-qwer-qwer-qwer/plans/1

{
  "actions": [],
  "metric": 123,
  "elapsedTime": 1234
}

Similarly, the client should have the power to stop the planning process and purged all the data:

DELETE /package/xyz/solve/qwer-qwer-qwer-qwer/

Note that that the URL structure does not need to repeat the /package/xyz/solve/ prefix, but if it does not, we have to come up with a different term for it, e.g. /request/qwer-qwer-qwer-qwer/

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions