The product-details library has grown over the years, adapting to a lot of changes. We'd like to refactor it to make it easier to work with.

Before the actual refactoring, we need to identify every current use-case.

Current source code: http://svn.mozilla.org/libs/product-details/

Use cases

www.mozilla.com (future part of www.mozilla.org)

• Offer download buttons for current versions for every locale
  • Firefox, Release, Beta and Aurora
  • Firefox Mobile, Release, Beta and Aurora
  • Thunderbird, Release, Beta and Aurora
  • Current version can be different for each locale
• Offer full list of download links for current and previous (3.6) version
• Variations for OS (Windows, Mac, Linux), architecture (32, 64 bits)

• Decide which version of a page we should display based on availability of a version (aka feature flags)

• Others?

affiliates.mozilla.org

• Get a list of locales and countries for users to choose from when signing up.

www.mozilla.org

Please add your usecases over here.

addons.mozilla.org

• Languages
• Default version of a product

developer.mozilla.org

• L10n language list

input

• We need to know the latest versions of every browser per channel e.g. 9.0a2 for nightly, 8a1 for aurora, 7 for beta 6 for prod

support.mozilla.com

• Identify legitimate Firefox versions to tag/filter support requests.

Since we use this data across multiple webheads, a way to store it in memcached or Redis (or even the DB) would be fantastic. Currently we're stuck with data cached in-process, read from files that are on each webhead (or on slow NFS mounts) which can get out of sync, and we have to wait for Python processes to restart before it updates.

mozilladanmark.dk

We use the json to find the latest version to construct download urls.

elmo

Offering downloads for localized builds would be nice. More importantly though would be an API to get the platforms that are available for a particular product. That'd be useful to create l10n-changesets.json, which includes which platforms we ship for which locale.

Your website

Please add your usecases over here.

Ideas for implementation

Those are some ideas written down. Definitely not set in stone.

• product-details should be a source of data first, with some PHP/Python methods to extract some of it based on some rules.
• shell commands to generate/alter the JSON, no manual editing
• download buttons should link to the download page when JS is disabled
  • Download links could be based on the visited locale instead of user agent
  • JS is only responsible for choosing a platform (OS + architecture)

Next steps

1. Get feedback from webdev, release engineering, l10n, community websites
2. Use this to have a clear picture of the needs of everyone
3. Code!