(
    title: "Current Projects",
    summary: None,
    published: Some((
        year: 2022,
        month: 5,
        day: 31,
        hour: 14,
        minute: 11,
        second: 3,
    )),
    tags: ["software", "programming", "rust"],
)
---
My attention has been a little divided lately between a number of different coding projects. I'm also taking on some contract work building web shiite with php, which is somewhat reducing my free time. That said, I've been doing some interesting things lately.
## Spartan support in GemView
I'm intrigued by Spartan. I'm not 100% sold yet, but I was intrigued enough to add support to GemView, which will land in the next release of the Eva browser. The full spec is pretty well supported, although I want to do a bit more with how prompts are handled. Right now clicking on a prompt link just pops up a file chooser. I want to instead give the user a dialog with a text entry box and an option to pick a file from disk, but not sure yet when I'll get around to it. I might also give an option for opening an external editor.

That said, browsing around Spartan sites works just fine.
## Rewritten Gemtext parser
When I first began the GemView and Eva projects I settled on a library which provided gemini connection and gemtext parsing so that I could focus on other aspects. I quickly realized it was a mistake when I found several bugs, one of which caused a panic in the parser. I filed bug reports and pull requests, but here we are months later and the author hasn't responded to any of it. So what I wound up doing is pulling the code right into GemView directly and integrated it with the codebase, making a rather large number of changes so that certain data structures could be shared between Gemini and the other protocols GemView supports, replacing Rustls with OpenSSL due to Rustls being too picky about certificates, removing the custom Url implementation in favor of the Url crate, etc.

The latest big change was rewriting the Gemtext parser from scratch. The one I inherited had a nested loop where it went line by line and then character by character for the first few characters to determine the line type. It had a 22 member enum of possible states that the parser could be in at any given time, leading to one massive parse function which was around 180 lines. This is exactly the type of code that I really dislike.

The new parser uses a completely different approach. There's still a loop, but instead of nesting another loop within it just does a pattern match to see what the line starts with. There's a total of three potential states that the parser can be in at any given time, and the largest function is 35 lines long. I also squeezed in a couple of extra features and removed a large number of allocations in the process. I'm quite pleased with this code.
## Toe and Agis
After implementing a few different network protocols in GemView I found that not only was the code not that difficult, but I was kind of enjoying writing it. I got curious to see what the other half of the connection would be like, so I wrote a Finger server (Toe) and then when that worked out I started work on a Spartan server (Agis).

=> https://codeberg.org/jeang3nie/Toe Toe repo on Codeberg
=> https://codeberg.org/jeang3nie/agis Agis repo on Codeberg

Toe is already in use on one of my Raspberry Pi servers. I like to think the code is pretty solid - certainly it can't be less secure than traditional Fingerd. Toe drops root priviledges after binding to port 79 and can be set to chroot into it's own directory. Displlaying any system information can be shut off if desired.
=> finger://hitchhiker-linux.org/nathan

Agis is in a more proof of concept state at the moment, but I did manage to test serving static pages last night. It's got a number of cool features that are implemented but not necessarily well tested yet.
* Multithreaded worker pool to serve requests
* Name base virtual hosts
* Traditional CGI support
* Aliases
* Redirects
* Directory indexes

The CGI interface is of the very old school /cgi-bin/ variety and should work with any type of script or binary you could throw at it. I'm also thinking of adding a handler directive, sort of like Apache's SetHandler, which would allow setting a script interpretor for another way to serve dynamic content that isn't as obvious as /cgi-bin/.

Agis is probably not quite production ready yet, but it's encouraging in it's current state. I think it'll be a nice server pretty soon.
