Given the scope and cross cutting nature of the issue, I think it's
something better handled by the CLI team via prioritized stories. Speaking
from experience, large PRs and PRs that involve refactors tend to be
painful for all involved.

If you'd like, I can raise an issue in GH. If you want a PR to simply add
yaml support to cups (which is what's most painful for me), I can probably
do that.

On Tue, Oct 27, 2015 at 2:32 AM, Koper, Dies <diesk(a)fast.au.fujitsu.com>
wrote:

Hi Matthew,



The commands you listed were developed over a span of several years, and
their options have evolved.

There is no technical reason for the missing options not to be added now
and implemented reusing each other’s code.

I think it’s mostly because there haven’t been enough user requests so it
hasn’t been prioritised.



PEM credentials for a user provided service is a good example of a use
case that’s not well catered for with the current specification.

Please let us know if you’d like to submit a PR to address this!



Regards,

Dies Koper

PM Dojo’er CLI team





*From:* Matthew Sykes [mailto:matthew.sykes(a)gmail.com]
*Sent:* Monday, October 26, 2015 12:00 PM
*To:* Discussions about Cloud Foundry projects and the system overall.
*Subject:* [cf-dev] json data and the cli



There are a number of places in the cli where a user needs to provide a
json payload to the cli. For example:



create-service/update-service

bind-service

create-service-keys

create-security-group/update-security-group



Depending on the command, the user can provide list of keys to be prompted
for, inline json, a pointer to a file containing json, or some
indeterminate combination of those options. That list bit is the problem -
there's no consistency across all of these commands.



Is there a reason why all of these commands can't use the same basic
infrastructure in the cli to provide a consistent behavior?



Also, when dealing with json data that contains new lines, it's very
painful for a human. (Think PEM encoded certificate chains as credentials
in a user provided service.) Given yaml is a superset of json, is there a
reason why we shouldn't or can't support yaml in the file representation of
the data?



Thanks.



--

Matthew Sykes
matthew.sykes(a)gmail.com

--
Matthew Sykes
matthew.sykes(a)gmail.com