Letâs put this on the agenda for Tuesdayâs meeting. A couple of observations:
Â
- Iâm not sure if the CSAR version should be related to the âcontainerâ format. For one, a processor canât get to the version until after unpacking the container.
You might be right that CSAR doesn't have to be linked to the container format. But if that's the case, we would need to update the spec, because it currently is linked.
I think that it is a good idea to link it. This gives guidance to TOSCA processors as to what they need to support. If we leave it implementation-specific there would be no portability at all.
By the way, I also glossed over the TOSCA-Meta-File-Version, which is currently at 1.0. That does not have to bump. That's what you can indeed only read after unpacking. But the CSAR version does refer to the container itself and its structure.
Â
- Do we really need to adopt a standard file name extension? Processors should be smart enough to try whatever the various supported container formats are an figure it out for themselves.
I do agree with this. For example, TOSCA source files are in ".yaml", not in ".tosca". The extension adheres to the format, not the content. In the same way I think a CSAR should be ".tar", ".tar.gz" (or ".zip" if we still want to support it? I hope not). I kept the ".csar" only for backwards compatibility, but it's also true that we don't have to be backwards compatible.
This is not what we currently have in the spec, so we would again need to update it. It's a good idea, I support it.