Fossil

Artifact [411ad9b27a]
Login

Artifact 411ad9b27adfa4ce78052eb469fad4dd1201e215c1f6610106a45ce47584d929:

Wiki page [To Do List] by drh 2020-12-01 14:15:20.
D 2020-12-01T14:15:20.446
L To\sDo\sList
N text/x-markdown
P 78746ae08a144f286adb78ba8b924c65e08b0f09729cdf213f9bad95868a5d80
U drh
W 10631
Things to work on:

  1.  Automated self-test

  2.  Add a diff option similar to --tk that shows the graphical diff in
      a web-browser instead of a Tk window.

  3.  Improvements to the "grep" command:
      <ul>
      <li> Search filenames given on the command-line or all managed files if
           no filesnames are supplied
      <li> Search the check-in named on the command-line or the 
           current check-out if no check-in is named
      <li> --from VERSION and --to VERSION 
           options to search a range of check-ins
      <li> --timeline, --tickets, or --wiki PATTERN to search things other
           than check-ins
      <li> --before DATE and --after DATE to limit the timespan of a search.
      <li> Always output filename and line number
      <li> Only show matches not found in adjacent check-ins, unless --all
           is used.
      <li> --earliest shows only the first match and --latest shows only the
           most recent match when grepping a range of check-ins.
      <li> -l just lists matching files
      <li> --diff-only only search the difference between check-ins
      </ul>

  4.  Change the PHANTOM table into a view on BLOB using a
      partial index where BLOB.SIZE&lt;0.

  5.  Prohibit database writes if any query parameters have been decoded
      but the request is not from the same origin.  This effort would benefit from
      an SQLite enhancement that allows "PRAGMA query_only" to be applied to
      individual database files, so that the repository can be made read-only while
      still allowing TEMP writes, as TEMP writes are used to compose intermediate
      results even on pages that are technically read-only.

  6.  <del>Implement a "`fossil backup`" command using VACUUM INTO.</del>
      Implemented in 2.12.  [Docs](/help?cmd=backup).

  7.  Multiple remote repositories.  Running "`fossil push`" pushes
      to them all, as does autosync.
      Partially implemented as of 2020-08-12:  Multiple remotes remembered
      but can only sync to one at a time.  [Docs](/help?cmd=remote)

  8.   Sync relay &rarr;  On a server, when another repository pushes to
       the server (or edits a wiki page on the server) the server
       automatically schedules a push to peer repos.
       Should be able to do this with hooks, but more testing is needed.
       Also, need a way to configure relay hooks in the Admin web interface.
       Consider also providing the ability to do an automatic GitHub relay
       via the same mechanism.

  9.   <del>Backoffice daemon &rarr; Instead of backoffice running in response
       to a web request, have a separate process that monitors multiple
       repositories and runs backoffice after "mtime" changes on the repository
       file, or periodically (every hour? every day?) in the absence of
       "mtime" changes.</del> Implemented in 2.12

  10.  Update preview using XMLHttpRequest instead of reloading the entire
       page. Implemented in /wikiedit and /fileedit as of 2.12 and /forum/...
       is pending.

  11.  <del>Allow help text to be in markup, either Fossil-Wiki or Markdown.</del>
       Implemented in 2.12

  12.  Search on help-text and/or on unversioned files
       <ul>
       <li> The "helptext" virtual table added by check-in 
       [b2dacfcd735d4b1c](https://fossil-scm.org/fossil/info/b2dacfcd735d4b1c)
       is a step toward providing search on built-in help text, but has not
       yet been integrated into the search subsystem.
       <li> There are so many configuration pages in the web interface now that
       it can be difficult to find the right page to change a setting.  One possible
       solution: Enhance the help text on all of the various setup 
       web pages, and then add a search box at the top of the main
       /setup page.  For maximum effectiveness, it might be necessary to
       add a new "Keywords" section to help pages that is not normally displayed
       but which is used for search.
       <li> It would also be good to add a search box at the top of
       the [](/help) webpage, perhaps
       </ul>

  13.  Documentation on sync-via-sneaker-net.

  14.  Macros or other mechanisms for embedding a last-update timestamp
       in the middle of text for wiki pages and/or embedded documentation.

  15.  Add a command-line variant of the /secaudit0 page and make that command
       accessible using "fossil all".

  16.  Improved transaction control:
       <ul>
       <li> Better detection of potential SQLITE_BUSY errors when promoting from
            a read to a write txn.  This will require SQLite enhancements.
       <li> On /xfer, only start a write transaction if the login has write
            permissions, thus allowing parallel clones.
       </ul>

  17.  On the [wiki page list](https://fossil-scm.org/fossil/wcontent), 
       omit wiki pages that are associated
       with check-ins and branches by default, but provide a button
       to show associated wiki pages if desired.

  18.  Add the ability to associate a forum thread with a check-in or branch.
       <ul>
       <li> Perhaps the linkage is based on the forum thread title, as is done for
            wiki pages.  But a fast lookup mechanism will need to be devised, as
            forum thread titles are not currently stored in the TAG table as are
            wiki page names.
       <li> Perhaps also provide forum-like threading to tickets.  Maybe merge
            the functionality of forum-post artifacts and ticket-change artifacts
            to allow both features within the same artifact.
       <li> Consider mechanisms to identifying check-ins or branches that include
            forum discussion when those check-ins/branches are displayed on the
            timeline, or on other pages.
       </ul>

  19.  Provide SSL capabilities for the "fossil server" and "fossil http" commands.
       <ul>
       <li> Because the website is not served from individual files on disk, standard
            tools for obtaining a LetsEncrypt cert won't work.  Some sort of mechanism
            to do this will need to be built into Fossil.  Or, a minimum, a mechanism
            should be in place to redirect requests to ".well-known" to files on disk.
       </ul>

  20.  Provide a setting that determines whether HTML content files are displayed
       as HTML or as plain text when browsing repository files.
       See the forum thread: <https://www.fossil-scm.org/forum/forumpost/cc9d20228d>

  21.  Client/Server mode or Shallow Clones.  Allow a remote repository
       to be opened without having to clone all history.

  22.  <del>Consider adding support for [interwiki link syntax](https://en.wikipedia.org/wiki/Interwiki_links).</del>
       Implemented by [](f4dc114a780fea41)

  23.  When entering a check-in comment using $EDITOR, there is no way to preview the comment.
       This is particular frustrating when there are hyperlinks or Wiki escape codes
       (like "`&lt;`" or "`&#91;`").  Errors result.  For example on
       [check-in 5244a5484a103065](5244a5484a103065) the comment was originally entered
       using a Markdown-style hyperlink.  Only after the commit completed was the error
       seen, and the check-in comment was fixed with a tag.

  24.  More ability to customize the [](/sitemap) page.  This page forms the basis for the
       hamburger menu on the skins that support the hamburger menu, so having the ability
       to customize the page would provide the ability to customize the hamburger menu.
       The current system allows enter four links for thinks like "Download" and "Documentation".
       More flexibility is wanted.  For example: <ul>
       <li> I'd like a link to this "To Do List" wiki page on the Fossil hamburger menu.
       </ul>

  25.  More "diff" links associated with Wiki.
       <ul>
       <li> With each wiki edit entry of the timeline.
       <li> On the submenu for Wiki display
       <li> On the wiki history display, provide more than current single-change diff.
            (Maybe the [/whistory](/whistory?name=To+Do+List) needs to be shown as a timeline
            graph rather than a simple list, so we can click on two nodes to get a diff.)
       <li> Diff links on editted Forum posts.
       </ul>

  26.  Add the ability to provide change comments on Wiki-Page edits.  The existing artifact
       format already supports this, but the code does not provide the user with an option to
       enter a change comment with a wiki edit, and any change comment that is entered is
       silently ignored, rather than being displayed in the timeline or on the /whistory page.

  27.  Timeline graph improvement opportunities:
       <ul>
       <li> [](/timeline?p=3814c9ff58e2f4ae&y=ci&n=20)
       <li> [](/timeline?b=20200608&n=22)
       <li> [](/timeline?p=2c9aa1b9391fa8c5&n=30)
       <li> [](/timeline?b=20200513&n=25)
       <li> [](/timeline?p=11d1233d305c0fd6&n=23)
       <li> [](https://sqlite.org/src/timeline?d=572f1ed59d29e74f&n=20)
       </ul>

  28.  New `manifest` setting options.
       <ul>
       <li> `manifest.h` &rarr; a C/C++ header containing macros like FOSSIL_MANIFEST_UUID and FOSSIL_MANIFEST_DATE.
            Programs can `#include` this header to gain easy access to version information.
       <li> How long after the previous will it be before there are requests for `manifest.json` and `manifest.tcl`
            and `manifest.py`?  Where do we draw the line?
       <li> Maybe instead of the previous two, we just add `manifest.date`.  That in combination with `manifest.uuid`
            provides most of the versioning information that most programs will need.
       </ul>

  29.  For the purpose of regression testing when changing the markup language formatters,
       provide test commands that will scan an entire repository for Wiki or Markdown-formatted
       artifacts (embedded documentation, Wiki, Ticket comments, Forum posts) and run them
       through the formatter.  Then, after making changes to formatters, we can run this
       command on various large repos both in the old and new version and look for
       unexpected differences.  We could also maybe run this test prior to each release.

  30.  New email notifications for administrators:
       <ul>
       <li> Alerts to any configuration change.
       <li> Periodic security audit reports.  (Dependency of ToDo #15.)
       </ul>
Z 92d6511390c41a41aa4d8edaad63f954