The blob regeneration (solving) part has been stable and
performant for over a year with no problems, even with web
crawlers constantly hitting it without needing rate limits.
All the other stuff is open to bikeshedding (as long as
my crappy hardware supports it :P)
/$INBOX/?r=$GIT_COMMIT -> HTML only
/$INBOX/new.atom -> Atom feed
/$INBOX/?r=$GIT_COMMIT -> HTML only
/$INBOX/new.atom -> Atom feed
-#### Optional, relies on Search::Xapian
+#### Optional, relies on Search::Xapian (or Xapian SWIG binding)
/$INBOX/$MESSAGE_ID/t/ -> HTML content of thread (nested)
/$INBOX/$MESSAGE_ID/T/ -> HTML content of thread (flat)
anchors:
/$INBOX/$MESSAGE_ID/t/ -> HTML content of thread (nested)
/$INBOX/$MESSAGE_ID/T/ -> HTML content of thread (flat)
anchors:
/$INBOX/$MESSAGE_ID/t.atom -> Atom feed for thread
/$INBOX/$MESSAGE_ID/t.mbox.gz -> gzipped mbox of thread
/$INBOX/$MESSAGE_ID/t.atom -> Atom feed for thread
/$INBOX/$MESSAGE_ID/t.mbox.gz -> gzipped mbox of thread
+/$INBOX/$GIT_OID/s/ -> "git show" (via "git apply")
+ This endpoint requires "coderepo" entries configured for
+ a given inbox. It can recreate ("solve") blobs from
+ patch emails using Xapian and git-apply(1). It can also
+ display non-blob content, but that remains a
+ work-in-progress.
+
+/$INBOX/$GIT_OID/s/$FILENAME -> "git show", raw output
+ As above, but shows the raw (usually text/plain) output.
+
### Stable endpoints
/$INBOX/$MESSAGE_ID/ -> HTML content
anchors:
### Stable endpoints
/$INBOX/$MESSAGE_ID/ -> HTML content
anchors:
git-config(1)
git-daemon(1)
git-fetch(1)
git-config(1)
git-daemon(1)
git-fetch(1)