tcl repository notes

• programmers looking for specific functions
• programmers looking for new features which might be useful (browsing)
• programmers looking for a specific package
• programmers looking for package docs
• users looking for a dependency (this part needs to be very simple)

• where do the docs go?

• must support binaries, source, pure tcl, starkits, .tm files.
• must handle multiple package types (source/binary/etc) and platforms for a single package. we could offer a small tcl installer that package maintainers could use, but the intention here is not to invent another packaging format or system.
• can contain multiple versions of packages. only latest is displayed by default but full version history available
• package documentation
• RESTful api for package management apps
• browse by package names, tags, dates, platform, license
• searchable by commands, name, tag, author, description, docs
• editing of metadata by maintainers after initial creation
• easy user contributions (include guidelines/howto)
• append comments to package pages (like php manual)
• rss feeds: tag, package, everything

• screenshots (per version or per package?)
• hosted version control
• trackers
• wiki per package

• command line or gui
• list installed packages and versions
• search available packages
• update installed package(s)
• install new package and dependencies
• remove package

• install in user sandbox and/or for the whole system
• ability for site administrators to customize the package list

• how to resolve name collisions? I think this will be up to the client

• certain metadata bits are required (keep it minimal)
• versions cant be replaced, only incremented. certain information is mutable without bumping the version, such as docs. data that is definitely not changable: name, license, released, provides

• browse
  • name
  • date
  • tag
  • license
• search
  • everything
  • advanced
• package home
  • released, license, provides, requires, etc
  • documentation
  • older versions
    • edit
• package edit
• account home
  • user info
  • projects
    • new
  • settings
• help/faqs
  • about
  • contributing

1. create a user account if needed
2. upload files (does it have to be a single file?)
3. app decodes files and captures as much metadata as possible
4. user fills out web form adding or correcting metadata
5. done

1. new upstream release, with a new version number etc.
2. a packager may have fixed a mistake in an earlier upload and needs to replace it. So, same release version number built from the same source release, but it should still count as an "upgrade".

1. upstream releases package foo version 3.4
2. packager builds binary foo-3.4-1.tar.gz, signs it and uploads it to the repository
3. packager finds mistake in packaging, needs to apply patch, or whatever
4. packager fixes problem, builds binary foo-3.4-2.tar.gz and uploads that.

1. use a client which uses the api (the client will present its own search, list, or other interface)

1. hit the front page
2. search, or browse by tag, etc

1. find a package
2. select a platform
3. select a version
4. select a package type (binary, source, pure tcl, etc) (optional)

  create table file (
  id integer primary key,
  filename varchar,
  size integer,
  checksum varchar,
  instance integer,
  foreign key (instance) references instance (id)
  );

  create table bundle (
  id integer primary key,
  name varchar,
  descr varchar,
  description text,
  provides varchar,
  -- key value pairs, eg home, docs, cvs, etc. should this be a table?
  links text,
  );

  create table instance (
  id integer primary key,
  bundle integer,
  version
  -- (binary/source/tcl/etc)
  type varchar,
  -- this only allows for one platform, but platform table could have entries like "unix", "windows", "all"
  platform integer,
  installer (configure/make,script,binary installer, none, etc)
  documentation text,
  uploaded_by integer,
  uploaded datetime,
  modified datetime,
  modified_by integer,
  released date,
  -- list of installed files?
  files text,
  -- sum of installed files
  size integer,
  commands varchar,
  author integer,
  license varchar,
  -- may create non "real" instances for purpose of depending on them
  real integer,
  foreign key (bundle) references bundle (id),
  foreign key (platform) references platform (id),
  foreign key (author,uploaded_by,modified_by) references user (id,id,id)
  );

  create table dependencies (
  instance integer,
  package varchar,
  -- exact, greater than, conflicts, etc
  type varchar,
  -- tip 268 style version spec
  version varchar,
  foreign key (instance) references instance (id)
  );

  create table platform (
  id
  name
  identifier
  );

  create table user (
  id integer primary key,
  username varchar unique not null,
  password varchar,
  realname varchar,
  email varchar,
  registered datetime,
  login datetime,
  -- may create non "real" users for purpose of authors
  real integer
  );

  create table perms (
  bundle integer,
  user integer,
  -- perm string is single letter, or word? multiple words/letters per row or multiple rows?
  perm varchar,
  foreign key (bundle) references bundle (id),
  foreign key (user) references user (id)
  );

  create table tags (
  bundle integer,
  tag varchar,
  foreign key (bundle) references bundle (id)
  );

  create table comments (
  bundle integer,
  -- what to do about anonymous comments? maybe nonreal anonymous user entry
  user integer,
  comment text,
  posted datetime,
  foreign key (bundle) references bundle (id)
  );

• data
• metadata
• authentication
• authorization
• result

• data - http post, scp?
• metadata - api (included in post), tpm file, web form
• authentication - http basic, cookie
• result - api: token or error via xml, web form: direct display

1. authenticated api call made, file and optional metadata supplied, token returned
2. api call made with token, returns not ready
3. instance entry is created in incoming db table. file is decoded to try to automatically determine any missing metadata. db row filled in
4. api call made with token, returns ok or more info needed
5. if ok then temp row is moved to real table
6. if more info needed then temp row expires after X days. user can log in and provide token to fill in missing data. missing data is returned with more info result so client can prompt user

1. logged in user presented with new instance form
2. file attached, optional form filled out, submitted
3. instance entry is created in incoming db table. file is decoded to try to automatically determine any missing metadata. db row filled in
4. results page refreshes every X seconds until ready
5. if ok then temp row is moved to real table
6. if more info needed then prompt user

1. MD5 or some other checksum so that a person can confirm they got the right thing
2. Some sort of authentication so that one can track what changes were made by whom (in case of bugs, trojans, etc.)
3. Packages should be able to be installed without the installer having to create special directories (don't assume things are going into /usr/local, etc.)
4. Packages should include doc - or at least a pointer to where to find doc
5. Authority location for package should be required
6. Orphan packages (where author has disappeared or ceased to be interested in supporting package) should be marked as such
7. Users of the repository should be able to relatively simply be able to determine what items are new