[OASIS Issue Tracker] Commented: (TOSCA-17) Packaging Format for TOSCA

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/TOSCA-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=30571#action_30571 ] 

Tobias Kunze  commented on TOSCA-17:
------------------------------------

Issue: Archive format

Main candidates are historically cpio, tar and zip, with zip being the de facto platform independent standard. However, zip being largely ignorant about what it zips up creates a number of issues that need to be dealt with. Specifically:

    1. Filesystem meta-information needs to be captured and re-created: specifically (*nix) permissions & ownership
    2. File meta-information needs to be captured and either prescribed or transformed: specifically, character set and encoding, but also platform-specific conventions such as line endings or byte ordering. E.g. a shell script copied to a Windows system and zip'ed up there will wreak havoc when run after extraction on a Linux system

Proposal:

    * Standardize on ZIP
    * Require a) that archivers capture filesystem and file meta-information in a suitable location (e.g. the manifest) and b) that extractors restore this meta-information, potentially transforming files in the process (TBD).


Issue: Java-isms

There is concern regarding basing CSAR on the JAR specification, which I share. Such Java-isms result in a hard sell to non-Java folks and are also often blind to non-Java issues (such as issues resulting from a tighter integration with the operating system).

Proposal:

    * Change the outward appearance of the spec to use generic, functional names rather than names borrowed from the JAR spec. E.g., instead of naming the meta-information directory META-INF, it could be called "tosca". Likewise, instead of calling the manifest "MANIFEST.MF", it could be simply "manifest", etc. There are many good solutions other than JAR and a good goal to have would be to look at (at a minimum) the Debian and RPM package structures and then decide on a new, platform-independent structure that embodies the platform-independent nature of TOSCA.
   * From a user uptake perspective, I would also propose to use "human friendly" formats wherever possible. For instance, instead of the "geek style" of keywords such as "Manifest-Version" (capitalized with dashes between words) in the JAR manifest, I'd posit that everyone would be much happier with simply "Version". Or, instead of "CSAR-Version", "CSAR Version" (although this is debatable; Debian packages, for instance place the archive structure version deliberately in a single, top-level "version" file). We should strive to keep files as human-friendly as possible, with as many declarations as possible having reasonable defaults (i.e. being optional).





> Packaging Format for TOSCA
> --------------------------
>
>                 Key: TOSCA-17
>                 URL: http://tools.oasis-open.org/issues/browse/TOSCA-17
>             Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
>          Issue Type: New Feature
>          Components: Spec
>    Affects Versions: CSD03
>            Reporter: Frank Leymann 
>
> Specifying a cloud application requires a number of different artifacts. In order to allow self-contained definitions of cloud applications a packaging format is needed that contains all the artifacts making up a manageable cloud application.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira