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

Determine Storage Scheme #1

Open
cbdotguru opened this issue Nov 24, 2017 · 2 comments
Open

Determine Storage Scheme #1

cbdotguru opened this issue Nov 24, 2017 · 2 comments

Comments

@cbdotguru
Copy link
Member

As specified here ethpm/ethpm-spec#75 we need to determine how to store packages such that the list can be enumerated and packages can be retrieved by name/uri.

Consideration should be given to either use functionality provided at https://github.com/ethpm/ethereum-indexed-enumerable-set-lib or https://github.com/Majoolr/ethereum-libraries/tree/master/LinkedListLib .

We should discuss the pros and cons of each implementation as well as determine if list order matters. Discussion should be had at ethpm/ethpm-spec#75 .

@pipermerriam
Copy link

Consider the following requirements from the side of a development framework consuming from a package index.

  • Way to pull all package names.
  • Way to pull all versions for a given package name.
  • Way to pull the URI for the release for a given package name + version.

Bonus points if it's easy for a client to cache the last seen release and to be able to use that information to only pull data on new releases.

Data structure:

  • package name: string
  • release: (version + URI)
    • version: string
    • URI: string

Some uniqueness constraints:

  • package names should be unique.
  • (package name + version) should be unique
  • URIs do not need to be unique.

Useful but not necessary metadata:

  • timestamp of when a release was published.

@cbdotguru
Copy link
Member Author

cc @paulohp

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

No branches or pull requests

2 participants