search

AI-Planning / planning-as-a-service

The newly improved planner (and more) in the cloud.
Apache License 2.0
30 stars 7 forks source link

Plan(s) listing in the `result` structure #41

Open jan-dolejsi opened 2 years ago

jan-dolejsi commented 2 years ago

I do not see a reason for exposing internal implementation details in the returned structure. If the planner finds multiple plans, they should be returned in a uniform structure such as 

{
  "result": {
      "plans": [
       ]
  }
}

Currently I see result.output.plan as well as result.output.sas_plan or result.output.sas_plan.1. We are bleeding implementation details through the interface. Or I at least cannot see any added value here.

I am not discussing here whether the content of the plans array should be strings (as today) or some rich structure. But it should be an array capturing plans in order of discovery.

haz commented 2 years ago

This is entirely up to the package author's discretion. It does bleed implementation details, but that's potentially extremely useful. E.g., maybe the FD deploy wants to return the output.sas (intermediate) file as well for other purposes.

jan-dolejsi commented 2 years ago

That is legitimate. But in that case there should be a clear indication of which of the entries are plans and which are something else. We are on the receiving side of this, so it cannot be completely up to the author's discretion.

haz commented 2 years ago

Completely agree, yep! "Extra stuff" can be just that, and a standard "this is a plan" can be used to parse things nicely as discussed in #36