Changes between Version 1 and Version 2 of ModuleEcosystem

Timestamp:

08/12/09 23:25:59 (12 years ago)

Author:

japhb

Comment:

Incorporate Allison's first review email notes; visual tweaks

ModuleEcosystem

@@ -19 +19 @@
      build and manage a module distribution network ...
    * However it should be possible for another group to do so.
+     * It is unlikely someone will try to mirror the entire history
+       of every dynamic language module ever made,
+     * But for instance serving torrents of Power Packs seems reasonable.
+   * The search API and install process be dead simple and clearly specified.
+     * Clone implementations used by other ecosystems will be a mark of success.
  * Toolchain
    * Basic tools can assume Parrot and the core modules are working,
@@ -41 +46 @@
      wiki, homepage, source repository, etc.
    * Allows disambiguation as per Perl 6 module spec (authorities,
-     versions, authors, etc.).
+     versions, authors, etc.), as well as equivalents for PHP PEAR,
+     RubyGems, Python Eggs, etc.
    * Specifies rules for dependency string parsing/interpretation.
 
@@ -47 +53 @@
 = Proposal =
 
-''''' This is a rough draft!  Suggestions welcome! '''''
+''''' This is a rough draft; suggestions welcome! '''''
 
  * Overview
@@ -61 +67 @@
      growth of the ecosystem until it stands on its own.
  * Metadata format
-   * Served metadata container is gzip'ed tarball (.tar.gz? .tgz?).
-   * Core metadata is in META.json at top level of container.
-   * Container includes copies of special files (e.g. README).
+   * Metadata served as JSON.
    * Format for specifying non-metadata-only build scripts undecided.
    * Integrity check / authentication methods undecided.
-     * Probably at least md5sum and sha1sum for source tarballs,
-       but what about when pulling from raw VCS repo?
+     * ''Probably at least md5sum and sha1sum for source tarballs,
+       but what about when pulling from raw VCS repo?''
+ * Metadata server API & UI
+   * Web form UI
+     * Enter/update/remove all module information (metadata fields)
+     * Deprecation/EOL
+     * Accept raw JSON block as alternative
+   * Simple HTTP/JSON API
  * Core modules
-   * parrot config  (already exists -- config.pir)
+   * parrot config  (already exists -- `config.pir`)
    * HTTP client    (at least GET, with redirect and proxy support)
    * zlib           (at least decompress)
@@ -76 +86 @@
    * version spec   (at least parse and compare)
    * library probe  (shared library info: present? version? location?)
-   * file paths     (portability: File::Spec + File::Basename + ...) 
+   * file paths     (portability: `File::Spec` + `File::Basename` + ...) 
    * file install   (portability: copy file, set file perms, etc.)
    * query metadata (perform API calls to metadata/search server)
    * installer lib  (all the real brains/glue for the module repo client)
-   * installer ui   (CLI and/or Readline, minimal brains, uses lib)
+   * installer ui   (CLI and/or `Readline`, minimal brains, uses lib)
  * Basic Batteries modules
+   * ''Note: Basic Batteries is just another Power Pack from a technical viewpoint; it is merely treated slightly differently in the community.''
    * Full versions of any modules that are limited in Core
    * Installer add-ons:   VCS fetch/use system pkgs/full depresolve/etc.
-   * Module author tools: create/register/update/upload/etc.
+   * Module author tools: easy create (module or pack)/register/update/upload/etc.
    * PIR-level tools:     disassembler/debugger/profiler/data dumper
    * NCI tools:           parse header/manage typemap/wrap C struct/etc.
-   * Standard interfaces: TAP, DBDI, logging, ?
-   * Standard libraries:  OpenSSL, DateTime, temp dir/file, ?
-
+   * Standard interfaces: `TAP`, `DBDI`, logging, ?
+   * Standard libraries:  `OpenSSL`, `DateTime`, temp dir/file, ?
  * Possible Power Packs (NOTE: '''EXAMPLES ONLY''', DON'T BIKESHED!)
    * Database:     DBDs (drivers), SQL clients, per-HLL DBI variants
@@ -103 +113 @@
    * Sound:        OpenAL, Pulse Audio, JACK, ...
    * Game Support: Require other Power Packs: Audio, 2D/3D Graphics
-
  * Misc recommendations
-   * Separate 'parrot-modules' mailing list for module creators/users
-     only if parrot-dev traffic gets overwhelmed.
+   * Separate `parrot-modules` mailing list for module creators/users
+     only if `parrot-dev` traffic gets overwhelmed.
    * Default to simple (CPAN-style) dependency resolution; upgrade to
      full resolution and system package awareness in Basic Batteries.
+   * Master metadata site will be `reponame.parrot.org`
    * Names so far suggested for module repository network:
      * Bird Words
@@ -116 +126 @@
        * Plumage
        * Roost
-     * Acronyms
+     * Acronyms ''(generally disliked, and leads to CPAN comparison/expectation)''
        * CPAAN
        * FPAN
@@ -130 +140 @@
    * version
    * license
-     * type
+     * type ''(standard short names for common licenses)''
      * uri
    * copyright_holder
    * abstract
- * Manifest fields:
+   * instructions
+     * type ''(standard names for common build sequences,
+       such as `cpan-mm` for CPAN + `ExtUtils::MakeMaker`,
+       or `custom` for custom instructions)''
+     * fetch
+     * configure
+     * build
+     * test
+     * install
+     * runtime ''(here for completeness; necessary?)''
+ * Manifest fields ''(still under discussion; for scriptless installs)'':
    * files
      * configure
@@ -145 +165 @@
        * lib
        * runtime
- * Dependency fields (as { [dep_name]: [version_spec], ... }):
+ * Dependency fields (as { [''dep_name'']: [''version_spec''], ... }):
    * provides
    * conflicts
@@ -157 +177 @@
  * Optional features fields:
    * optional_features
-     * [feature_name]
+     * [''feature_name'']
        * description
-       * [any/all dependency fields as needed]
+       * [''any/all dependency fields as needed'']
  * Other optional fields:
    * description
@@ -181 +201 @@
        * project_uri
      * mailinglists
-       * [list_name]
+       * [''list_name'']
          * address
          * uri
  * Undecided fields:
+   * ''How do fields get added to spec?  Allow custom fields?''
    * dynamic_config
    * no_index