
! Current Big Design Issues


This is a list of what I currently think are the biggest issues to
address for a 1.0 release.  Most of these will eventually be busted
out into their own topics.

-*-*-

---

* Distributed Transactions

  Atomic commits to multiple projects.  This is desirable both for
  projects consisting of lots of different sub-projects, and for 
  a topic renaming feature in LabNotes/.

---


* The Test Suite and Formal Specs

  Are obviously critical for a 1.0 release.


---

* Issue Tracking

  I badly need a bug/issue tracking system.  After looking around at the
  alternatives, I'm convinced that rolling my own using LabNotes/ is
  the way to go.


---

* Longer Version Numbers

  Investigate how hard it would be to support an optional third
  number in version numbers.  Or, an optional arbitrary number of 
  numbers.  Or, something even more general (perhaps rethinking
  category/branch as well).  _Too much_ generality here will greatly
  complicate implementations and layered tools, while not increasing
  usefulness all that much -- however, too much generality is something
  users have been asking for...


---

* Faster, nicer, `mkpatch'/`dopatch'

  A preliminary attempt at `mkpatch'-in-C showed that `mkpatch' performance
  can be _much_ better and at the same time, the output format can be a flat
  file instead of a directory.

  This is critical to get right early since:

     *) It represents a change to archive formats.

     *) It's critical for low-latency and "high-bandwidth" commit.

  The performance issue has two aspects: on the one hand, `arch' should scale 
  upwards to handle (with excellent performance) project trees the size of,
  say, the linux kernel or a complete bsd distribution.  It should also 
  scale _down_, in the sense that it should handle very small project trees
  _extremely_ quickly (at least for local archives), with very low latency.

---

* Library Drives Repository Mode

  Currently, repositories drive libraries.  All transactions take place
  in repositories, and libraries are just an ancillary database that can
  be built and incrementally updated from a revision library.

  This should work both ways, at least as an option.  For _local_ transactions,
  it should be possible to commit to a library, then have a repository which
  is built and incrementally updated from the library.

---

* Systas Scheme Binding

  SystasScheme/ needs an `arch' module.  

  While start-up time and portability problems make SystasScheme/ a
  poor choice to implement the 1.0 client tools, eventually those
  problems will be solved -- so we can have a Scheme-extensible client.

  Systas is starting to provide a nice library for writing web services.
  Currently it provides a decent extensible CGI engine with modules for 
  user account management and login-session management.  Those parts, 
  together with an `arch' binding, would make a nice basis for doing
  SmartServers.

---

* Smart Servers

  A very modest server, equipped with a server-side revision library,
  can serve deltas between arbitrary revisions.  To a with-ftp client
  -- this would look like an ordinary file system; to the server,
  those files are built-on-demand (perhaps with caching).

  One thing this will complicate is the heuristic used in `build-revision'
  that's supposed to find the quickest way to build a particular revision.
  With smart servers, that heuristic has to be updated to take advantage
  of smart servers.  `delta-patch' would need to change too.

  Another nice trick is server-side triggers.  The repository update protocol
  involves just a few FTP operations, some of which have the significance
  of marking transaction boundaries.  Server-side hooks on those operations
  can support server-side transaction triggers.

---

* New Web Browser

  The web browser is handy, but a garbagy implementation.  It needs to be redone.
  Probably it should _not_ be based on the idea of generating only static pages :-)
  I wonder if can't be entirely dynamic -- working off a revision library instead
  of its own files.

---

* selected files `commit'

  Make it possible to commit just a few files from a tree
  with many modifications.

  This is tricky, though -- what if tree restructuring has
  taken place, for example.  Lot's of cases to work through
  and design.



%%% tag: Tom Lord Wed May  1 23:20:14 2002 (ArchRevCtl.d/BigIssues)
%%%
