w3c / echidna

New publication workflow at W3C — main component
https://labs.w3.org/echidna/
MIT License
38 stars 49 forks source link

Implement a real format and parser for the manifests #111

Open astorije opened 9 years ago

astorije commented 9 years ago

At the moment, the manifests are quite clumsy, I think. They have to be text files, one line per file, and the first one is always and automatically read as the main file, renamed Overview.html, even if Overview.html is present somewhere else in the manifest. It has also some serious security flaws that we'd like to avoid¹.

But it is and always was a temporary solution to release Echidna faster, and to poll opinions before coming up with a more definitive solution.

In this issue, I'd like to start a discussion with those who already use manifests. What would be your preferences for such system? Should it stay a file-based format, move to JSON, YAML, etc.? What would be an example of manifest you'd like to have in your repos? When submitting a manifest to Echidna instead of a plain document, should it be detected by its filename (like Travis CI does, for example), its content-type, the first line inside the document, ... ? Or simply not detected, a boolean to the HTTP request specifying if it's plain or manifest? How do you see integration with generators such as Respec (note that spec generators also trigger their whole world of problems)?

I think any calm discussion will help improving the system :-)

¹ And until this is fixed, we'd also like our super nice editors to not try to mess up with our system :P

darobin commented 9 years ago

If the manifest is JSON, you can detect that you're getting a manifest just by knowing that you're retrieving an application/json document.

astorije commented 9 years ago

Working on that one now.