Returned plans should be parsed and returned in a well structured way; plan cost including

[jan-dolejsi]

Some planners return their entire diarrheas output into the result.output.plan field. Some return a properly formatted plan as text. The original /solve interface returned the plan in a rich Json structure. The planutils should be able to parse and standardize the plan structure between temporal and strips planners.

The plan cost is also included in different formats in the planner output. With bit of luck, one can get the plan from result.output.plan field and find the cost from the result.stdout. But as soon as you have multiple plans, you cannot figure out what belongs to what.

Ideally, result.output.plan should be a structured element with steps or actions if you want as well as cost and/or makespan and possibly the search stats such as statesEvaluated.

[haz]

As mentioned elsewhere, this comes down to package-specific setup. We could insist that packages adhere to a particular format (their plans go to a file and not stdout, etc) before they are officially included as part of the main PaaS deploy, but in general, a package is free to define the manifest (and thus endpoints) however they'd like.

Would this be an issue to perhaps have the manifest flag if they follow the "planner output standard X", in which case we could/should parse & package up things?

[jan-dolejsi]

The planners should have the flexibility to output to stdout or to files. I agree.

But either way, they should standardize to one of the supported plan formats. The plan parser may be rather flexible, but it needs to be able to unambiguously discover, where plan starts and where it ends.

The VS Code PDDL extension is already doing fair bit of that.

https://github.com/jan-dolejsi/pddl-workspace/blob/master/src/parser/PddlPlannerOutputParser.ts
https://github.com/jan-dolejsi/pddl-workspace/blob/master/src/parser/PddlPlanParser.ts

• tests ...

https://github.com/jan-dolejsi/pddl-workspace/blob/master/test/parser/PddlPlannerOutputParserTest.ts

[haz]

Well single+multiple plans is standard enough to enforce for inclusion in PaaS. The planner/package manifest can point to the file location, and perhaps indicate the style of plan output (just action sequence with ; comments, temporal plans, something different), and then have dedicated code in PaaS to attempt a parse. We followed this strategy with the legacy solver:

https://github.com/AI-Planning/cloud-solver/blob/master/process_solution.py

For those packages that are just dumping plans to stdout, we can lean back on the authors and give them the ultimatum to fix it, or be removed from the remote service ;).