-- Leo's gemini proxy

-- Connecting to senders.io:1965...

-- Connected

-- Sending request

-- Meta line: 20 text/gemini; lang=en;

Figuring out the API


I made some decent progress on my server today. It's still very-very green, It supports most things except client certs for sure (though I've only really tested a few types of requests and responses). But it's super clunky to program with.


The server setup


What I am struggling with is what is the primary interface a developer wanting to build something with my server should use? On one hand I want it to be intutitive and clear, relying on built in Java types and just reading the method signature should be easy. But on the other hand. You should be able to bootstrap the server and be writing your own code, not trying to awkwardly plug implementations into a map where the key is the path it should trigger for?


I've made a huge mistake


I also realized for client certs you'll most likely need to have more than JUST the URI of the request when handling it, so I may need to redo all of my interfaces which are built around:


interface RouteHandler {

    ResponseMessage handle(URI uri);

}

Where ResponseMessage a status code, meta string, and byte[] of data (optionally). What this lacks is at the time of handling the URI having any other request context like the caller, their cert, is this authed? anything for me to provide information back to the route. It shouldn't be a hard overhaul but something I realize and is making me feel a bit discouraged.


Why not show some code?


I am holding off publishing this because I want to actually vet it first in production 1, but 2, I also feel a major rewrite happening maybe building off of a standard I use at work with how to break apart your logic.


I have already built a lot of lower level server logic like "How to handle SNI" "How to handle URIs by URI path" "How to server files" "How to handle input" where it's all intuitive, but the implementer would need to know and use it, which feels awkward for me, and I built it this way!


So before I make it more visible I want to be sure the code won't go through a complete rewrite. I am doing this for myself, for fun, so I don't care if anyone ever sees this. But I also have some really fun ideas for things to build into my site:


adding tags to my gemlogs and add a tag based directory

+1s to gemlogs that you've enjoyed

reply reposter - submit a URI that is a reply to one of my gemlogs (this really should be a CGI so others can use it, but I'll prototype it here)

and a personal project idea I don't want to announce just yet


Most of these can be done without this server being built, but I like the idea of having it all homegrown.


Gemini cgit/sr.ht?


I feel like I've seen some READMEs rehosted on gemini, but I haven't seen a source tree/ commit log browser. I'll probably pop into IRC later to ask. I typically host my code on Github and or my personal (public readonly) cgit. But tips for making gemini related code visible on gemini would be great!


Devlog?


I also don't want to commit to a /devlog/ just yet. So sticking with the gemlog for now :)


Links


Devlog Part 1 "Starting a Devlog"

Gemlog

Home


-- Response ended

-- Page fetched on Wed Apr 24 10:34:37 2024