The road to an IRIX email client: request for community help - Printable Version
+- IRIX Network Forums (//forums.irixnet.org)
+-- Forum: SGI/MIPS (//forums.irixnet.org/forum-3.html)
+--- Forum: Development/Porting (//forums.irixnet.org/forum-9.html)
+--- Thread: The road to an IRIX email client: request for community help (/thread-3740.html)
+- IRIX Network Forums (//forums.irixnet.org)
+-- Forum: SGI/MIPS (//forums.irixnet.org/forum-3.html)
+--- Forum: Development/Porting (//forums.irixnet.org/forum-9.html)
+--- Thread: The road to an IRIX email client: request for community help (/thread-3740.html)
The road to an IRIX email client: request for community help - Raion - 11-08-2022
Greetings!
This is a little bit more of a formal thread and this is one that I would like to have some input from people from SGUG, so if somebody wants to speak on the behalf of the contributors who don't want to contribute here that's fine; I just want to try to include them in the conversation when possible.
It's been pretty well established that we have been left behind in a number of areas and I want to tackle one of the more "easy" ones first with a new concept that I thought of.
Let's discuss an ideal native email client. I have a suggested architecture, but let's go through the features that we might want in an ideal email client before we get into a discussion of architecture.
Community members please discuss what features are crucial. For parity's sake and ease of use, I have a handful:
1. SSL/IMAP support. A lot of the older email clients only support pop which is kind of dated. SSL and TLS support are obviously quite necessary.
2. Multiple mailboxes. Doesn't necessarily have to be like Mozilla Thunderbird or anything but we should have the ability to switch between them pretty easily, IMHO.
3. Motif GUI. Judging by the hubbub that was around the Motif Netsurf and IRC clients I think this is pretty much a given for everybody.
Here's a few question marks, I suppose:
1. Should we support pop? I don't think there's any mail providers that really are around anymore that only support pop; but it might be preferred for people to use that and I just don't know.
2. Is displaying HTML messages important?
3. RSS feeds or other integrations like you see with Mozilla Thunderbird or other common email clients?
4. GNUPg integration?
I'm obviously probably missing some of other people's features so please feel free to chime in at this point and tell me what I'm overlooking.
Architecture for an email client
I obtained the idea for this from looking at the architecture of the transmission torrent client. Suffice to say that client has a useful feature where it can have a daemon running in the background and you can have everything from a web, command line interface or a curses interface.
In order to be pragmatic about the development of this email client I think that it would be necessary to start in stages:
Stage 1: daemon and library for various frontends. A reference frontend in the form of a curses-based user interface for email.
Stage 2: a prototype Motif interface in Motif Lua so that we can more easily adjust and adapt it to people's preferences. Basically we build a reference design out and then later on port it to C or Viewkit C++ if necessary.
Stage 3: a web-based front end if necessary so that you can access it from other machines but this might not be strictly necessary.
I think that this would be a pragmatic way to develop this because then you could also have customizable interfaces built around it and it could also have some widespread appeal from people outside of the community. But that's just my two cents on it and I would like to see people being included in the conversation because I've already decided that one of the future projects that we're going to embark on with TruHobbyist, Linear and all of the other amazing developers that have joined the community in recent years, is this. So if you want to be part of the conversation and the eventual design please step forward and I am more than happy to listen to people who actually know what they're talking about and tell me that I might be thinking about this the wrong way. I just want to continue to help the community in the best way I can until I am capable of developing such applications myself which is coming but pretty slow going because it takes time to learn all this stuff for yourself.
RE: The road to an IRIX email client: request for community help - commodorejohn - 11-08-2022
Dividing up the backend and frontend Transmission-style is a good idea from a modularity/maintainability standpoint, but I can't think of a scenario where you'd need to store mail/run the daemon on one machine and access it from another that wouldn't already be covered by modern mail providers' nearly ubiquitous Web clients, so developing a bespoke Web client seems like unnecessary duplication of effort. It would make the frontend an easier lift if you only wanted browser-based mail access, but if you're planning on doing a Motif version anyway, may as well just focus on that.
RE: The road to an IRIX email client: request for community help - Raion - 11-08-2022
Hey people have developed tools before that are strangely obtuse and we're working with a lot of crazy people here myself included so such quirkiness would not be out of the question!!!!
RE: The road to an IRIX email client: request for community help - TruHobbyist - 11-09-2022
(11-08-2022, 07:50 PM)Raion Wrote: 1. SSL/IMAP support. A lot of the older email clients only support pop which is kind of dated. SSL and TLS support are obviously quite necessary.Crucial
(11-08-2022, 07:50 PM)Raion Wrote: 2. Multiple mailboxes. Doesn't necessarily have to be like Mozilla Thunderbird or anything but we should have the ability to switch between them pretty easily, IMHO.Crucial
(11-08-2022, 07:50 PM)Raion Wrote: 3. Motif GUI. Judging by the hubbub that was around the Motif Netsurf and IRC clients I think this is pretty much a given for everybody.I would add Qt as a GUI option. A relatively old Qt version with support for IRIX (C++98) and some multimedia support would ease this task and help in both UI and UX.
(11-08-2022, 07:50 PM)Raion Wrote: 1. Should we support pop? I don't think there's any mail providers that really are around anymore that only support pop; but it might be preferred for people to use that and I just don't know.Last time I configured one of my desktop email clients (eM Client: https://www.emclient.com/, Win10), it still used POP by default. Since this was just a couple years ago and the client in question has a good reputation on the internet, I assume there is still some use of POP/POP3 out there.
(11-08-2022, 07:50 PM)Raion Wrote: 2. Is displaying HTML messages important?If going that path, CSS would need to be supported too. This would make the client way more useful but also restrict this usability to a GUI frontend.
If supporting only simple text, the client could still be used for private email exchange. In this case I would say all expected email functions should be implemented: attachments, reply, forward, carbon copy, et.al.
(11-08-2022, 07:50 PM)Raion Wrote: 3. RSS feeds or other integrations like you see with Mozilla Thunderbird or other common email clients?Personally, I don't use this one.
(11-08-2022, 07:50 PM)Raion Wrote: 4. GNUPg integration?A lighweight email client with support for S/MIME and or PGP would be great! I would send my emails from now on encrypted just to brag about having sent them from IRIX
(11-08-2022, 07:50 PM)Raion Wrote: 5. AttachmentsI can imagine a user friendly interface for managing attachments, which is done horribly on any other email client/service I have encountered:
A combination of traditional UX and more modern interfaces like WhatsApp/Telegram/Signal, where the selection and filtering process of attachments is easy, straightforward and extremely fast.
This is how it would work:
Attachments are saved as objects in the client. Let's define these as an "AO" (Attachment Object). An AO can contain any number of attached files. So the client remembers in a chronologically sorted list, all AOs created and used in emails. By managing them independently of the emails, they can be easily reused: just pick the corresponding AO from the list.
Creation of an AO: Define the relevant logical environments to filter attachments from, in increasing order of size: single email, entire dialog, all emailS, whole client (<- this includes the local filesystem). Select attachments through checkbox, click "create" and your AO is ready to be used.
Filtering is done in any environment and can include filetype, name, size, date, ... . Technically every filter is just a for loop.
The problem I want to solve with this is to reduce the time of bundling together all required attachments from: local filesystems and email attachments spread across multiple different emails. This task is not easily solved, not even in GMail.
(11-08-2022, 07:50 PM)Raion Wrote: Architecture for an email clientThe latest developments on more exotic OSs like HP-UX or OpenVMS, are to access different administrative applications using a web interface. It's a very cheap and portable way of achieving interoperability.
I obtained the idea for this from looking at the architecture of the transmission torrent client. Suffice to say that client has a useful feature where it can have a daemon running in the background and you can have everything from a web, command line interface or a curses interface.
In order to be pragmatic about the development of this email client I think that it would be necessary to start in stages:
Stage 1: daemon and library for various frontends. A reference frontend in the form of a curses-based user interface for email.
Stage 2: a prototype Motif interface in Motif Lua so that we can more easily adjust and adapt it to people's preferences. Basically we build a reference design out and then later on port it to C or Viewkit C++ if necessary.
Stage 3: a web-based front end if necessary so that you can access it from other machines but this might not be strictly necessary.
Being able to access my email client running on IRIX using PuTTY or any web browser from any machine from the mid 90's up to today's PCs, is definitely a good idea.
My two cents.
RE: The road to an IRIX email client: request for community help - Raion - 11-09-2022
(11-09-2022, 10:42 AM)TruHobbyist Wrote: I would add Qt as a GUI option. A relatively old Qt version with support for IRIX (C++98) and some multimedia support would ease this task and help in both UI and UX.
As an option maybe, but it'd have to be QT3 and below. As I said, there's lua bindings for Motif so ease of prototyping is there. I would want the flagship for this to be Motif for obvious reasons; QT has a nonnative UI, and it has issues with text shaping just like later GTKs do due to lack of GL support for antialiasing in either library.
(11-09-2022, 10:42 AM)TruHobbyist Wrote: If supporting only simple text, the client could still be used for private email exchange. In this case I would say all expected email functions should be implemented: attachments, reply, forward, carbon copy, et.al.
I'm leaning towards no HTML for the client for better curses support.
(11-09-2022, 10:42 AM)TruHobbyist Wrote: A lighweight email client with support for S/MIME and or PGP would be great! I would send my emails from now on encrypted just to brag about having sent them from IRIX
Same!
(11-09-2022, 10:42 AM)TruHobbyist Wrote: I can imagine a user friendly interface for managing attachments, which is done horribly on any other email client/service I have encountered:
A combination of traditional UX and more modern interfaces like WhatsApp/Telegram/Signal, where the selection and filtering process of attachments is easy, straightforward and extremely fast.
This is how it would work:
Attachments are saved as objects in the client. Let's define these as an "AO" (Attachment Object). An AO can contain any number of attached files. So the client remembers in a chronologically sorted list, all AOs created and used in emails. By managing them independently of the emails, they can be easily reused: just pick the corresponding AO from the list.
Creation of an AO: Define the relevant logical environments to filter attachments from, in increasing order of size: single email, entire dialog, all emailS, whole client (<- this includes the local filesystem). Select attachments through checkbox, click "create" and your AO is ready to be used.
Filtering is done in any environment and can include filetype, name, size, date, ... . Technically every filter is just a for loop.
The problem I want to solve with this is to reduce the time of bundling together all required attachments from: local filesystems and email attachments spread across multiple different emails. This task is not easily solved, not even in GMail.
As long as the implementation of any FS ops doesn't use glib I'm ok with this idea. Glib is one bit I think deserves a slow painful death.
(11-09-2022, 10:42 AM)TruHobbyist Wrote: The latest developments on more exotic OSs like HP-UX or OpenVMS, are to access different administrative applications using a web interface. It's a very cheap and portable way of achieving interoperability.
Being able to access my email client running on IRIX using PuTTY or any web browser from any machine from the mid 90's up to today's PCs, is definitely a good idea.
My two cents.
Thank you for your input Tru.
RE: The road to an IRIX email client: request for community help - linear - 11-09-2022
i think a QT frontend would ultimately be a waste of development effort and i'm not sure what it would offer that a Motif frontend wouldn't, but i won't go as far as to stand in your way if you want to write one.
i think a good architecture would be to standardize on Maildir, have a backend daemon that does nothing but fetch from remote servers and stuff into Maildir, and a frontend which reads from Maildir and allows configuration of the backend (and can start it when launched if it isn't running).
this would also allow interop with other clients like aerc, mutt, pine/alpine, etc.
RE: The road to an IRIX email client: request for community help - Lady Serena Kitty - 11-09-2022
I don't agree that we need Qt, tho a number of useful apps may be written using Qt. Might I suggest a middle-of-the-stroad appurroach and say we make a Qt compawtibility layer backed by Motif?
I dunno if anykitty else has noticed this or not, but using a desktop that has GTK and Qt apps side-by-side is a bit off-putting, there's no consistency!
RE: The road to an IRIX email client: request for community help - Raion - 11-20-2022
So linear and I had a little bit of dialogue a while ago on this. There's a bunch of maildir compliant applications that can probably be shoehorned into being part of this setup. I'm still trying to figure out how I want to even manage the future crowdfunding operations however so I'm a long way off from doing anything with this