[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cacao] [EXT] [cacao] Remaining work items
In addition to Jason;s request I still havenât heard whether the metadata writeup that was written will be merged/added to the spec to help explain all the metadata properties we have in the spec.We seem to be going in the wrong direction as far as getting close to being complete on the spec. We might need a special session that everyone can make to discuss and resolve the issues. Unfortunately the meeting times havenât worked out for me and given that Marlon wasnât able to make the call today either then we might want to consider a specific call next week to resolve.AllanOn Nov 1, 2022, at 3:08 PM, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:Hi folks - wondering if someone can link to the detailed proposal being discussed? As Stephanie has recently left IBM I am trying to get back up to speed on CACAO and Allan's argument is concerning.ÂFrom:Âcacao@lists.oasis-open.orgÂ<cacao@lists.oasis-open.org> on behalf of aa tt <atcyber1000@gmail.com>
Sent:ÂTuesday, November 1, 2022 6:41:50 PM
To:ÂDr. Desiree A Beck <dbeck@mitre.org>
Cc:ÂduncanÂsfractal.comÂ<duncan@sfractal.com>; Bret Jordan <jordan.oasisopen@gmail.com>;Âcacao@lists.oasis-open.orgÂ<cacao@lists.oasis-open.org>
Subject:Â[EXTERNAL] [cacao] Re: [EXT] [cacao] Remaining work itemsÂDesiree - This proposal effectively still makes the feature required.ÂThis Message Is From an Untrusted SenderÂYou have not previously corresponded with this sender.ÂMost, if not all, playbooks will like have commands and if we are stating that a command must also define the meta-data that describes what the command is doing then this effectively makes the entire feature required.Secondly, this is absolutely the worst possible scenario of all because it is equivalent to requiring every single shell command within a shell script have to have a functional description of what that command is doing *in addition* to the actual command itself.ÂThis proposal results in extremely verbose playbooks with absolutely every single command having to have a descriptor in addition to the actual command itself.I am strongly opposed to this proposal as it will result in making playbooks bloated, overly cumbersome to define and effectively will result in playbooks not being defined or used at all.I suggest that all playbook metadata be optional and let the market/authors decide what is practical and reasonable to document. This is exactly the same as what occurs with other scripting languages. People comment on commands and scripts based on what they want to convey. They donât do it on every single command as itâs not required and would slow the development of the scripts down to a crawl.AllanOn Nov 1, 2022, at 11:54 AM, Dr. Desiree A Beck <dbeck@mitre.org> wrote:Regarding the required/optional issue â as discussed on todayâs call, weâd like to propose the following compromise:Â- TheÂplaybook_functionalitiesÂproperty on Playbook is optional- TheÂplaybook_functionalitiesÂdescription includes a normative "SHOULD" (i.e., âThe values for this propertyÂSHOULDÂcome from theÂplaybook-function-type-ovÂopen vocabulary.â)- TheÂfunctionÂproperty on Command Data is requiredÂDezÂFrom:Âcacao@lists.oasis-open.orgÂ<cacao@lists.oasis-open.org>ÂOn Behalf OfÂduncanÂsfractal.com
Sent:ÂThursday, October 27, 2022 4:26 PM
To:Âaa tt <atcyber1000@gmail.com>; Bret Jordan <jordan.oasisopen@gmail.com>
Cc:Âcacao@lists.oasis-open.org
Subject:Â[EXT] Re: [cacao] Remaining work itemsÂOn the required/ optional issue, I favor optional. I hear Allanâs arguments and I resonate with allowing new users to crawl before running. If it's that valuable the market will reward the optional feature. Remember customers can require optional features. It just means not everyone requires it in all cases. Plus making required would be a breaking. Just my 2 cents.ÂDuncanÂÂÂiPhone, iTypo, iApologize
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]