💾 Archived View for bbs.geminispace.org › s › misfin › 19440 captured on 2024-12-17 at 15:05:03. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
If I write a misfin server and a client, which protocol spec should I target? Is there any "known good" implementation I can test interoperability against? Thank you.
Sep 06 · 3 months ago
🕹️ skyjake [mod...] · Sep 06 at 15:05:
I decided to support both B and C versions for now. An important practical difference is that B's requests are limited to 2048 bytes total, while C has a much larger maximum content length (16 KB).
Personally, I'm not sold on Misfin(C)'s use of a TAB character to separate the content length from the recipient URI, but at least it's differentiable from a Misfin(B) request.
🚀 clseibold · Sep 29 at 00:32:
@skyjake Yeah, I remember making that decision and debating with myself and with the others on whether we should use a tab or space.
We went with the tab so that a misfin(C) request actively failed on misfin(B) servers, and this allowed clients to determine whether a server was B or C. If it was B, the C request would always fail, then the client could retry with a misfin B request.
I wasn't too sure at the time whether everyone would move over to C or if lem would accept any of the changes we proposed (and lem-two had just announced they came back, only to never login again; I hope they are doing okay).
So I felt it was important that C servers can use B requests, and C clients can fallback to B requests for B servers.
If I had known whether everyone would switch to C or not, I would probably just have used a space, but I didn't want to risk lack of interoperability in case we had a fractured ecosystem.
Anyways, I learned a lot from helping with the C spec. We used this trick and a few others, and this allowed me to realize that we need to use tricks to limit this type of extensibility in protocol specs, lol.