I can't really come up with a strong argument against using fastcgi :thinking:
Yeah i think you’re right. My issue is the huge added complexity of the http server. If it could be swapped out w a simpler framework or there is a solution like cgi that may make sense. I avoided cgi bc caddy (the web server i use) doesn’t support it. Will have to think abt it more. Thanks for your feedback
On Aug 8, 2021, at 3:25 AM, Johann Galle firstname.lastname@example.org wrote:
I think maintaining two completely different modes does not make sense, the better idea would be to switch. I also do not think generating all these HTML files is a good option.
IMHO the most sensible approach would be to dynamically generate pages, and leave the actual server stuff to something else. This is already more or less the intended use case, because mygit does not support HTTPS, so that would need a proxy already anyway. Maybe CGI would be a good solution for this, but at least that would be the general idea. We should probably look at what e.g. Apache, Nginx, caddy etc. support in this direction.
-- View on the web: https://todo.sr.ht/~aw/mygit/46#event-93995
I am increasingly unhappy with the complexity of having to run a full HTTP server inside mygit. I think I would prefer a static host, like stagit: https://git.codemadness.org/stagit/file/README.html
This could be a build flag perhaps
g clone --verbose https://git.alexwennerberg.com/mygit Cloning into 'mygit'... error: The requested URL returned error: 500 (curl_result = 22, http_code = 500, sha1 = 7b7a56defa702f432dd0dbca0ee0ff21aeb4537c) error: The requested URL returned error: 500 (curl_result = 22, http_code = 500, sha1 = 7fabf5ccee3a82d95d423987b7080e523d330021) error: The requested URL returned error: 500 (curl_result = 22, http_code = 500, sha1 = 7a2c946b1994488aaf45a69ed54db2d636d6fa31)
Here's a very very rough sketch of what I have so far if you're interested: https://git.alexwennerberg.com/crabmail
so you can do like
Threading like hypermail is very annoying if you want to read an entire thread. All other collaboration platforms I know show everything for a thread (i.e. "issue", "pull request", "merge request" etc.) on one page. Sourcehut, Gitea, Gitlab, Github all do it this way.
Yeah, this is what I was thinking as well. When I say "hypermail style" I just mean a static script that takes an mbox and outputs HTML, rather than a dynamic serer. I hadn't thought about the plus addressing system -- I was thinking just threading based on the in-reply-to header
In the end my idea is also to process a mbox file, and I have seen that maildir should probably also be supported as more tools like mbsync seem to support it.
Makes sense to me!
I may write it in Go to use email libraries like this: https://git.sr.ht/~emersion/go-emailthreads (or i could rewrite that lib in Rust, depends how much time I have)
I think what you’re describing is slightly different— I wouldn’t expect self hosting a mail server to be common at all (I don’t host email), and so my primary case would be to pull via imap
It’s surprisingly hard to find good IMAP scripts these days, most of them are ancient. I may bundle in something with this project or write a simple imap backup program in Rust
Hmm, I'm not super familiar with local mail delivery, and I've been working on a version of this, but my idea was basically to just clone hypermail https://github.com/hypermail-project/hypermail -- ie, use something like isync to sync mailboxes to a maildir/mbox, then convert that maildir to a bunch of HTML files.