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

First draft for compressed data packages #198

Closed
wants to merge 1 commit into from
Closed

First draft for compressed data packages #198

wants to merge 1 commit into from

Conversation

sabas
Copy link

@sabas sabas commented May 26, 2015

This spec states only how to archive or compress and which extension to use.

See #132

@rufuspollock
Copy link
Contributor

@sabas apologies for slowness on merging - i have been looking at this and just been mulling some points over.

@danfowler - i'd also invite you to do a quick review here :-)

@danfowler
Copy link
Contributor

@sabas @rgrp if I'm understanding correctly, the datapackage.json file would be compressed along with the data files, right? This would mean some extraction operation would be required in order to read basic metadata about the package.

@rufuspollock
Copy link
Contributor

@mfenner would you like to review this?

@sabas
Copy link
Author

sabas commented Sep 24, 2015

It's just a draft for discussion :-) The problem of discovering the metadata is interesting, something like the jar manifest? https://en.wikipedia.org/wiki/JAR_(file_format)#Manifest

@pwalsh
Copy link
Member

pwalsh commented Sep 24, 2015

@sabas wouldn't the datapackage.json in a compressed Data Package be the equivalent of a manifest file in a JAR?

@sabas
Copy link
Author

sabas commented Sep 24, 2015

Yes @pwalsh I linked it as a reference for a possible implementation. The datapackage manifest would be the datapackage.json

@mfenner
Copy link

mfenner commented Sep 24, 2015

In the spirit of keeping things simple I wouldn't provide two options (.dp and .dpz). And in the spirit of not reinventing the wheel I would look at https://researchobject.github.io/specifications/bundle/, which uses Universal Container Format (UCF). Or for a software packacking example Chrome extensions: https://developer.chrome.com/extensions/packaging

@mfenner
Copy link

mfenner commented Sep 24, 2015

Pebble watch files are another example: http://www.pebbledev.org/wiki/Applications/

@tfmorris
Copy link

tfmorris commented Oct 9, 2015

I'll second @mfenner 's suggestion to exhaust all possible existing alternatives before defining a new format. If you are forced to define something new, I'd strongly consider using zip instead of tar, since every other container format in the world from JAR to EPUB to Research Object Bundle has settled on it. There's an old overview of a bunch of the zip-based formats here: http://broadcast.oreilly.com/2009/01/packaging-formats-of-famous-ap.html

@rufuspollock
Copy link
Contributor

OK, it sounds like we do want to go with zip. I'm going to close this PR for the time being and suggest we move discussion back to the main issue at #132

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

Successfully merging this pull request may close these issues.

6 participants