Hello,

> What about partially ordered plans?  Also, shouldn't there be a way to
> indicate that action a further expands into actions b and c, say?

Planner9 supports partially-ordered task networks but always produces 
fully-ordered plans. The goal can be partially-ordered, although the API 
I proposed does not support it, but maybe it should?

The specification of actions (tasks) expansion is done in the planning 
domain. The proposed API allows to specify the planning problem, not the 
domain. The domain could be loaded by the planner node from a file, for 
instance written in YAML. We could imagine to specify the domain 
dynamically, but I'm not sure it makes sense; do you see a use case in 
which it would be useful?

> Is the constants field necessary?

The idea is to use it to link the meaning of constant identifiers to 
their names, for debug. If we switch to strings for constants, it is not 
needed anymore.

> Second Martin's suggestion that these be turned into a single
> actionlib interface to planners.

Agreed.

> Is there a reason why constant symbols are integers but relation
> symbols are strings?  Might be good to just use strings for everything
> so messages are human readable.

Yes there is a reason: The relations are defined in the planning domain, 
therefore strings are the only way to refer them from the problem, 
excepted if we retrieve from the planner a mapping of these names to 
identifiers. The constant symbols originate from the client of the 
planner, therefore it can use strings because it knows their meanings.

What I like with the integers constants is that the parsing is kept to 
the minimum. But if everyone else in the community prefers strings, I 
will not try to impose my view.

Kind regards,

Stéphane

-- 
Dr Stéphane Magnenat
http://stephane.magnenat.net