This is a design document to collect ideas, strategies and discussion for a new design of qooxdoo-contrib.

If you want to add to it, please edit this page. In the simplest case just append your items at the end. Even better, insert and mark your thoughts at appropriate places. We'll try to keep this page "list-ish", so it will be easy to add indented list items as comments. Please sign each entry e.g. with your initials so it's attributable without stepping through the page history.

• Contributers should be free to store and maintain their code where they wish. (th)
• The core team will supply the infrastructure for the contrib catalog, which lists the available contributions, some meta-info, and a URL to the root directory of the code. (th)
• The generator will support inclusion of contributions in application projects through the existing contrib:// pseudo URL schema. (th)

• Contributers should be free to store and maintain their code where they wish. (th)
  • This doesn't preclude that there will be a certain number of common "nests" where authors can choose to manage their code in a common environment (e.g. in a "qooxdoo-contrib" SourceForge or Github project). (th)

• Contribution Demobrowser. (th)

• The core team will supply the infrastructure for the contrib catalog, which lists the available contributions, some meta-info, and a URL to the root directory of the code. (th)
  • All that is mandatory at this point is the URL which must allow download of the contribution code as individual files, in the well-known contribution structure. (th)

• The generator will support inclusion of contributions in application projects through the existing contrib:// pseudo URL schema.
  • The configuration will be the same as it currently is, only the semantics will change (The actual web URL is not constructed from the pseudo schema, but looked up from the catalog). (th)
  • The psuedo URl schema would support pulling from any svn or git url, whether sourceforge, github, or a private repo. (js)
    • I think besides contrib:// we could support http:// and ftp://. But I wouldn't want to support SCM clients like svn or git. (th)
  • The contrib's Manifest.json or config.json could list other, dependent contribs which would be recursively fetched by the generator. (js)