=== Package Hierarchy ===

{{{
vitamin
  io
  locale
  convert
  text
  cipher
  log
  store
  c
  sys
    darwin
    linux
    windows
}}}


 * There's no placeholder for std ... and, presumeably, object.d would have to sit in the ''vitamin'' root?
 * The name ''store'' (or ''data'') is a placeholder for containers. The latter is too long to type over & over?
 * If you haven't tried it, type the word ''vitamin'' a few times. It's not the easiest sequence to type either :)

=== Alternate Heirarchy ===

{{{
vitamin
  lang
    std
  core
    io
      model
    math
    memory
    thread
  locale
  stdc
  posix
  platform
    darwin
    linux
    solaris
    windows
}}}

 * The include path will contain these directories:
   * vitamin - all vitamin libraries hang off this directory
   * vitamin/lang - any language support headers or other immovable code goes here
 * Each package will contain these files at the top level (assume these samples are for the "cool" library):
   * [wiki:SampleAboutFile about.d] - contains a library description and other general text
   * [wiki:SampleConfigFile config.d] - contains any library-wide configuration, most notably one or more pragma(lib,"") declarations so the library file (and any dependencies) are automatically linked
 * All source files in a package will include a module description, author, copyright, and license information, and will include the package's config.d file, using something akin to [wiki:SampleModuleFile this boilerplate format].

==== Should we merge some of the above bullets with the "suggested conventions" in the main Wiki page? ====

Here's yet another suggestion; this one merges the previous two, adds DDL, and is an attempt to retain short paths for oft-used packages:

{{{
vitamin
  io
  ddl
  log
  stdc
  text
  math
  store
  cipher
  locale
  convert
  sys (or 'os'? Also houses platform-independent OS modules Thread, Time, Error, etc)
    posix
    linux
    darwin
    windows
    solaris
  lang (or 'core'? D runtime stuff)
    std
    memory
    runtime
      typeinfo
      util
}}}

or perhaps this flattened housing of the D runtime/language support, where the members of ''runtime'' has been moved into ''lang'' itself:

{{{
  lang (or perhaps 'runtime', or 'core' ?)
    std
    memory 
    typeinfo
    util
}}}

resulting in this variant:

{{{
vitamin
  io
  ddl
  log
  stdc
  text
  math
  store
  cipher
  locale
  convert
  sys
    posix
    linux
    darwin
    windows
    solaris
  lang 
    std
    util
    memory 
    typeinfo
}}}

The grouping, or hierarchy, here is pretty loose. A stricter hierarchy would probably move ''convert'' with the confines of ''text'', and ''cipher'' into some other, new, subset. However, this somewhat lax structure has some useful properties: the packages likely to be used in more programs have the shortest path, the platform-specifics are all isolated nicely, and the language/runtime support is nicely packaged (other than the std.intrinsic problem). But perhaps more importantly, the somewhat lax structure makes it easier to add further packages without fretting about rearranging things to suit. In short: too strict a hierarchy may tend to beg restructuring over the long term, and refactoring such a hierarchy would be a major issue for the user-base. Probably a deal-breaker. Thus, while this style of grouping may not be entirely ''proper'', it may well be a practical compromise?

Oh, and if you mirror two of these in the horizontal plane ... it looks just like a christmas tree. That has to count for something :)

== Concrete Implementation ==

Now that we're actually building the lib, it's starting to take this form:

{{{
tango
  io
  ddl
  log
  core
  stdc
  text
  math
  store
  cipher
  locale
  convert
  net
    ftp
    http
    pop3
    smtp
  os
    posix
    linux
    skyos
    darwin
    windows
    solaris
}}}

Note that we changed the name to tango instead of vitamin. A chunk of tango.io was moved to tango.net (all the socket oriented modules), and a number of placeholders for net-based protocols have been added on an experimental basis. Http is currently the only protocol implemented, and operates as an example of what might be forthcoming. Also added is an http server, but this should probably be relegated to some kind of "add on" package. At this point, the http server acts as a red-flag for resolving how do deal with such "add ons".

Note that the various lang modules have disappeared - most of that has been moved out of the primary branch into a "third-party" section. For instance, all the dmd compiler support code, including the gc implementation has moved out of the primary branch. This is intended to enhance library flexibility with various compiler implementations.

=== Points of discussion: please add to this whenever you see something awry ===
 
 * tango.io.Print should probably be moved to tango.text as well as be renamed to something that don't shout "Print to paper" ;)
 * we need to resolve the multiple Unicode implementations
 * need to resolve how to "extend" the lib with third-party functionality
 * should cipher be moved into math?
 * tango.store needs a better name
 * core.System needs to merge into something else
 * do we need a core.Interval, to describe interval periods rather like core.System does, and leverage this throughout rather than depending upon correct interpretation of opaque integers?
 * object.d imports a couple of things from stdc -- should we try to minimize such dependencies?
 * cipher needs a base64 implementation to round it out 
 * should cipher be renamed tango.crypto?
 * should tango.locale be moved inside of tango.convert?
 * tango.locale uses .net layout format, whereas tango.convert.Format uses printf