Version 2 of the API will add better serializers, unifying both Remote File Manifests and Globus Manifests into a singular internal model which can be expressed in either format. The service may switch from using Bags as the internal format for storing remote file manifest information, and use simple JSON for storing manifests instead. This is due to Globus Manifests allowing for files to be specified without a checksum, which is in conflict with the BDBag spec requiring each file to have one or more checksums from the four ['md5', 'sha1', 'sha256', 'sha512'].
Additionally, the current way models are defined is very messy with its handling of JSON data. This is mostly due to the Models not being well normalized, which results in much of the JSON being stored in text fields. This isn't really a problem in the classical sense of needing to do SQL joins on specific fields, but it results in dirty serialization/deserialization from explicitly translating data to and from JSON strings.
Another fairly major change will be switching away from automatically registering each manifest with a Minid. This results in a lot of 'throwaway' identifiers where a new published datasets have errors and need to be resubmitted. New manifests will be created and with a UUID, where the user may decide to publish a manifest with an identifier at a later time.
V2 will include support for Globus Automate as a Globus Automate action provider, for both creating and transferring manifests.
The new basic API spec is here (only transfer action provider spec shown):
Version 2 of the API will add better serializers, unifying both Remote File Manifests and Globus Manifests into a singular internal model which can be expressed in either format. The service may switch from using Bags as the internal format for storing remote file manifest information, and use simple JSON for storing manifests instead. This is due to Globus Manifests allowing for files to be specified without a checksum, which is in conflict with the BDBag spec requiring each file to have one or more checksums from the four ['md5', 'sha1', 'sha256', 'sha512'].
Additionally, the current way models are defined is very messy with its handling of JSON data. This is mostly due to the Models not being well normalized, which results in much of the JSON being stored in text fields. This isn't really a problem in the classical sense of needing to do SQL joins on specific fields, but it results in dirty serialization/deserialization from explicitly translating data to and from JSON strings.
Another fairly major change will be switching away from automatically registering each manifest with a Minid. This results in a lot of 'throwaway' identifiers where a new published datasets have errors and need to be resubmitted. New manifests will be created and with a UUID, where the user may decide to publish a manifest with an identifier at a later time.
V2 will include support for Globus Automate as a Globus Automate action provider, for both creating and transferring manifests.
The new basic API spec is here (only transfer action provider spec shown):