The AEA framework makes a multitude of tradeoffs.
Here we present an incomplete list of known limitations:
AEABuilderchecks the consistency of packages at the
addstage. However, it does not currently check the consistency again at the
loadstage. This means, if a package is tampered with after it is added to the
AEABuilderthen these inconsistencies might not be detected by the
AEABuilderassumes that packages with public ids of identical author and package name have a matching version. As a result, if a developer uses a package with matching author and package name but different version in the public id, then the
AEABuilderwill not detect this and simply use the last loaded package.
The order in which
teardownare called on the skills, and
actis called on the behaviours, is not guaranteed. Skills should be designed to work independently. Where skills use the
shared_contextto exchange information they must do so safely.