This is a first step towards making task data work more like the script engine. Ideally, users would be able to extend a data spec to customize how task and workflow data is stored and retrieved, and would be similar to @jbirddog 's work on datastores. The existing dictionary mechanism (which would remain the default) works fine for simple data but is insufficient for large or complex data.
There are a few other places where code would have to be updated to use this, but would require a serialization migration to do it properly. The migration would be very simple, but I don't want to introduce it between creating a release candidate and a release.
The bigger obstacle is the parser -- you could extend the data spec, but there is no way to tell the parser to use it, and adding such a mechanism to the existing parser would be onerous.
This is a first step towards making task data work more like the script engine. Ideally, users would be able to extend a data spec to customize how task and workflow data is stored and retrieved, and would be similar to @jbirddog 's work on datastores. The existing dictionary mechanism (which would remain the default) works fine for simple data but is insufficient for large or complex data.
There are a few other places where code would have to be updated to use this, but would require a serialization migration to do it properly. The migration would be very simple, but I don't want to introduce it between creating a release candidate and a release.
The bigger obstacle is the parser -- you could extend the data spec, but there is no way to tell the parser to use it, and adding such a mechanism to the existing parser would be onerous.