Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Different output formats #2

Closed
spekulatius opened this issue Aug 9, 2015 · 6 comments
Closed

Different output formats #2

spekulatius opened this issue Aug 9, 2015 · 6 comments

Comments

@spekulatius
Copy link
Member

To allow automatic validation of the output it needs to be easily machine readable (e.g. as a JSON or XML). Currently this isn't an option.

@NightJar
Copy link
Contributor

Hi @spekulatius - are you able to elaborate a little on your vision for this issue? The module currently doesn't output anything, merely caches the info for future use.

Did you intend to:

  • add a controller to allow this to be consumed somehow?
  • update the build task to live-report on what it found?

If the latter, do you think it's necessary? It would basically be re-creating the output of the SensioLabs module e.g. JSON example found at https://security.sensiolabs.org/api (base of page)

{
    "symfony\/symfony": {
        "version": "2.1.x-dev",
        "advisories": {
            "symfony\/symfony\/CVE-2013-1397.yaml": {
                "title": "Ability to enable\/disable object support in YAML parsing and dumping",
                "link": "http:\/\/symfony.com\/blog\/security-release-symfony-2-0-22-and-2-1-7-released",
                "cve": "CVE-2013-1397"
            }
        }
    }
}

@spekulatius
Copy link
Member Author

Hey @NightJar

Its been a while. I'm not sure I can recollect the idea behind this. You are right that it would pretty much replicate the Sensiolabs API as it looks. Should we just close it?

Cheers,
Peter

@NightJar
Copy link
Contributor

I think adding an access point for external consumption would be dangerous, so I would imagine this was probably in the form of an export, such as the one found on most ModelAdmin pages.

We have converted silverstripe-maintenance into a report, which supports export as CSV. The idea behind the extensions in #34 is to link the two and provide extra report fields*, which would provide this in part - with the exception of various formats.
(*which I've just realised I've left out - but that's OK there are tests to fix yet it seems.)

The issue with hooking silverstripe-maintenance report is that exporting currently requires it - where this module does not require silverstripe-maintenance, nor provides any interface at all for that matter.

Would you prefer us to keep a separtae (admin) interface at the ready for this module? It could include multiple export formats, and probably even only optionally enabled via config.

@spekulatius
Copy link
Member Author

Hello @NightJar

originally this module itself didn't have any way of exposing the information - for good reasons. The maintenance module did this job. I'm happy to keep it this way.

FYI @robbieaverill

Cheers,
Peter

@NightJar
Copy link
Contributor

Neat, thanks for the timely responses @spekulatius - I'll just close this :)

@spekulatius
Copy link
Member Author

No worries @NightJar

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants