Re: [Edbrowse-dev] mailx

[Adam Thompson <arthompson1990@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4224 bytes --]

On Sun, Apr 12, 2015 at 12:00:47PM -0400, Karl Dahlke wrote:
> > we need ...  imap (with imaps and starttls support),
> 
> Handled by curl, to some degree.

Thought so, but it's the "to some degree" part which concerns me.
> > pop3 (with ssl and tls support),
> 
> Already done, mostly by curl.

I was fairly sure this was the case.

> > mbox and maildir support (for local mail),
> 
> I wouldn't use this; keep mail on the server or put mails
> on your computer where they really belong.

You wouldn't but, if we want to make this more than a project used by only a
hand full of people, we need this support.
I personally need to access my local mbox because I have things like cron jobs
which occasionally fail and their emails land in my local mbox.
Also, I used to run an email server (and know people who do the same)
which could receive email from the internet (and had the relevant dns records
set up to make this happen) but for which the method of email access was
maildir via a local email client. At the end of the day,
edbrowse is the *only* email client I know which doesn't do this.
Well the only Linux one at least.

> > Correct threading header support (currently it doesn't work correctly,
> 
> It does, but you have to save email unformatted and browse and re.
> I need to make this mechanism more convenient from a user perspective,
> but it is implemented inside.
> I had to do this a few years ago because people on one of the linux
> lists yelled at me, each of my emails started a new thread
> and confused them and I really meant it to be a reply on a current thread
> so anyways yes I did some of this work.
> It wasn't hard.
> I think it's documented somewhere.

Could you possibly demonstrate this by *not* starting a new thread when you
reply to this email (and all emails actually);
Put me down as one of those users who'll start yelling at you for this.
It's quite annoying when using a client like mutt, which does threading, when
your replies appear out of order with the rest of the thread.
Actually, add threading to the requirements for an ebmail program.

> > Other stuff ...
> 
> Yes, not sure how vital the other stuff is.

Probably not very, but it's worth designing things in such a way that additions won't be too complex.

> > but I wonder if it's time for an edmail program?
> 
> We can certainly see the advantages of the separate eb js process,
> now that it's done,
> and ebmail ebspread etc could make a lot of sense, as long as it's all an integrated system.
> Bill Gates found this out a long time ago.
> Some web forms call up email client so you can send email,
> or even submit form by email,
> and from within email you can click on a link and go to your browser,
> and (not speaking of windows but of edbrowse)
> I can be in the editor and suddenly decide I want to send somebody email
> and just put subject at the top and type sm and out it flies.
> I really like that.
> I really like the integratedness of it all,
> but that certainly doesn't preclude modularizing the software more than it is today.

I'd probably go for a system whereby users could define commands,
thus you could define the sm command to use ebmail,
whereas I'd probably use mutt (until ebmail becomes a usable email client for me).
I'd definitely define something to launch (what'd the browser be called in this
naming system?) on a URL though. Basically what I'm proposing is a system which
can be as integrated as *you* want, but flexable enough for users like *me* to
make our own choices as to the programs we use to carry out certain operations.
I'm trying to design away from the single does everything for everyone model of
Windows (and to some extent some of Gnome etc on Linux),
and more towards the provides tools to do everything model of *nix.
Actually, I think even Windows provides ways for you to override the defaults for things.
Personally, if ebmail can be as fully featured as what I've currently got then
I'd really like to use it, but I'd like options and don't particularly want to
get into designing separate programs which are, under the surface,
very tightly coupled.

Cheers,
Adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]