Sender: clseibold@auragem.letz.dev (Christian Lee Seibold)
Received on 2023-10-05 21:30:08
You bring up some great points @satya! Ok, so I think the best approach right now might be to go with one protocol that can support imitating both traditional POP3 and IMAP, depending on what the user wants and how the client is configured. This was already a thing POP3 could technically do, just with a few missing features like flags and folders, but POP4 was an unofficial spec that added these things on top of POP3. The way POP3 imitates IMAP is by always using the UIDLs of messages (unique-id listings), which were persistent ids, instead of the session-dependent ids of messages, and then a client would send delete commands for the specific messages deleted. POP4 added a way to change the *current* folder of the session, which saved the previous current folders updates (deleted messages marked deleted, etc.). And POP4 added flags for tracking read state, visibility, flagged email, etc. I think imitating POP4 gives us the best of both worlds.
But of course we also want to simplify POP4 for GMAP too. My final idea is that GMAP gemini "endpoints" (URLs) should be general enough that they work for GMAP supported clients, but can also be used as the endpoints for geminimail interfaces too. This reduces redundancy for those implementing support for both in their server, and simplifies creating geminimail interfaces.
If anyone else has any more thoughts, please do chime in!
-
Christian