Open subtleGradient opened 11 years ago
subtleGradient
commented
11 years ago First thought off the cuff...
To add metadata for 42_O01I.CIA in the cia50-a pack...
Add the file "cia50-a/42_O01I.CIA.json"
So there would be one json file for each individual art file.
subtleGradient
commented
11 years ago This json data could be loaded up into a MySQL db or whatever and vice-versa. But keeping a copy of it all as simple text files in github unblocks contribution. Anyone can fork the repo and send a pull request to submit metadata.
subtleGradient
commented
11 years ago Maybe just one json file per pack to start out.
subtleGradient
commented
11 years ago We could generate all the json files with what information we know already. That way people can contribute changes simply by clicking Edit in GitHub.
The generated files would include the sauce data and place holders for all the data we wish we had. As well as a URL to the PNG version of each file in the pack.
subtleGradient
commented
11 years ago YAML may be a better option. JSON syntax is too strict and doesn't handle merge conflicts well.
lordscarlet
commented
11 years ago I think this is something worth looking at. However, I told @subtleGradient privately: if this is just an attempt to shortcut the route to metadata, I think the master branch is actually really close to being live, and takes care of most of the metadata entry. I don't think we need to do this just in order to have metadata anytime soon.
ispyhumanfly
commented
11 years ago I still find value in exposing at least the option of retrieving metadata in various formats. .json, .yaml and .xml would be nice.
All of this would spawn from our metadata project. For instance, any art pack could be requested directly by URL. If you request a pack and specify .json or .yaml or .xml you'll. receive all meta data associated with this pack in the format requested.
I think it will allow m any third party developers to get access to our data in a encoding type their more familiar with, or, in a format that their module supports directly.
_dan
Sent from my mobile device.
On May 21, 2013, at 11:30 AM, Doug Moore notifications@github.com wrote:
I think this is something worth looking at. However, I told @subtleGradient privately: if this is just an attempt to shortcut the route to metadata, I think the master branch is actually really close to being live, and takes care of most of the metadata entry. I don't think we need to do this just in order to have metadata anytime soon.
— Reply to this email directly or view it on GitHub.
lordscarlet
commented
11 years ago Agreed. Like I said, I think it is a valuable endeavor, and linking it to github to allow multiple modes of editing sounds particularly intriguing. I just think @subtleGradient was partially looking for a way to quickly get to metadata. I think we should get to metadata and then start generating these files. From there, we can work on a way to have actual .json/.yaml files that can be edited and synchronized with the database.
bricas
commented
11 years ago @ispyhumanfly well, the api portion satisfies that -- i mean, @cwensley is already using it with PabloDraw.
ispyhumanfly
commented
11 years ago And I guess I'm talking about an "extension" the the API, where we leverage the API, metadata to create seemingly static .json, .xml, .yaml files that act as "containers" for an archive and its related data.
I'm just talking about a new feature build on top of what we've already done.
sixteencolors.net/archive_name.json sixteencolors.net/archive_name.yaml sixteencolors.net/archive_name.xml
Are we doing that now?
_dan
On May 21, 2013, at 1:09 PM, Brian Cassidy notifications@github.com wrote:
@ispyhumanfly well, the api portion satisfies that -- i mean, @cwensley is already using it with PabloDraw.
— Reply to this email directly or view it on GitHub.
Similar to CommonJS/Node.js package.json file standard?