Well - you're diving in to the most difficult part - the command line interface.
And this is where a minute of thought is worth a megabyte of programming,
and where I need most help since I don't know a lot of imap.

> Should we completely replace POP with IMAP,

I really wouldn't want to do that.
Some old-school folks, like me, will probably use pop forever.
I look at all my mail from one computer so it's easier for me
to grab the mail and deal with it, piece by piece, locally,
and thus I rarely have a backlog of rmore than 5 emails,
whereas somehow my wife typically has a thousand, sometimes 2 thousand.
And pop3 is already written and works so why trash it?
And there may be a mail server out there somewhere that still only offers pop3.
But yes the user interfaces would be different,
and imap commands may not be pop3 backward compatible in all respects,
though i would like them to be where possible, and at some level.

.ebrc
map { ... }
A new keyword, imap, would declare this an imap service.
I think this is all we need change here.
Other attributes login password ports servers etc could all stay.
I'll make this addition, since I know that code well.

> What should the user interface to IMAP look like?

I think I really like the direction you are headed here.

> fetches a list of folders with unread mail.

Or should we fetch and show all folders?
Maybe I don't even remember my folders, and if I'm smart I won't have that many.
It's ok if a line in the display says

command list 35/35

I've read all the mail in that folder but that's ok.
I still may want to download some emails, delete them,
move some to another folder, etc.
More on this below.

> With IMAP, "inbox" is a special folder name.
> It's where most mail goes by default. We'll
> guarantee that if inbox has any unread messages, it goes to the top

Yes.

> After the list is displayed, edbrowse displays a command prompt.

I suppose it could, though it normally doesn't.
I mostly find a command prompt in this context to be annoying.
The old ed of 1975 you could ask for a command prompt of *
with the P command, but I never turned it on,
and so I didn't even implement it in edbrowse, though it wouldn't be
hard to do, and would be backward compatible with ed.
Bring up ed and try it.
Type P and see the * prompt.
(That's a capital P)
So if we really wanted some kind of prompt here, and I personally don't need 
one,
but if we want one maybe it should be universal throughout edbrowse, *,
and toggled by the P command, like ed.
I have in fact left P unused for this reason.

> 1. inbox 10/24
> 2. edbrowse-dev 3/10
> 3. family 4/7

This is good!

> If you hit enter here, no command, you select the first folder with

Enter = 1, or g1

Showing my ignorance here, is imap just a list of folders
or can it be a directory tree of folders?
Can you have folders within folders?
If the latter then we may want ^ to go back up the tree, and g/ to go to the 
top.
If imap is just a flat list of folders than we don't need all that complexity.

> If you want to go to a specific folder, you can do that with the g
> command.

It would be nice if this was compatible with the menus in an input form.
When I'm on an html page and entering my address
and there is a drop down list of countries, sometimes 220 countries,
I can read through the list if I like, or I can just type
in the number of the item if I happen to know it, i=37,
or I can type in a fragment of the name, like i=united to snag
united states, being a case insensitive match.
I really like this interface and might want  to use it again,
at least in spirit, for the imap folders,
for those folks who really might have a lot of them.
I mostly don't like tab completion, and never use it,
but certainly don't mind it being there, if the other stuff is there too.
The rl command can switch between tty and readline,
just as it does in edbrowse.
Anyways there may be some routines I wrote that we can reuse,
to look through the list and match on number or text fragment.
So continuing your example, I would type

g2 or g ed or g dev

any of these would get me to edbrowse-dev.

> The main screen will offer a handful of other commands:
> p (poll server for new messages)

Would redisplay the list with the new counts??

> c (create folder)
> d (delete folder)
> a (redisplay list, showing *all* folders, including those with 0 unread

Ok I hadn't seen this before.
Maybe this would meet my needs of showing all folders,
and then it would be ok just to show the unread folders by default.
Maybe l lists the folders with unread mail.
I guess it depends on whether you have few folders or many.
I know I would have few, but some folks might have many
and might not want to slog through all 100 upon startup,
so I get that.

> After selecting a folder, edbrowse will display the first unread message
> in that folder, the same way it would display a message today.

I like this - step through the unread emails and let me "dispose" of them.
Could I use most of the existing pop3 commands as I do now?

w write to file formatted
W write to file and delete
u write to file unformatted
U write to file unformatted and delete
n next email, marking this one as read
space continue reading this email
d delete completely
These are all as they are today,
or nearly so except for the w W distinction for
deleting the email from the server or not.

Rendering email currently uses all the html machinery but not js.
Would we continue to do this?
If an email really needs js to run properly
I bring up the unforrmatted version locally, browse, and run.
Is this a good strategy for pop, or imap, or both?
Emails requiring js are quite rare,
and js was so buggy I wanted to leave it out.

> imap gives us a few extra options for dealing with that message,

Yes it does.
m move to another folder.
Again we can specify folder by number, text fragment within the name,
or tab completion.
a step through attachments.
I would save them locally on my machine using same interface as today.
but the email still sits on the server.

> Once you've finished with the unread messages in the folder,
> you're thrown back to the flist of folders described above.

Yes, perfect.
Maybe one more command to "stop" reading the unread emails here,
maybe there are just a lot of them, and go back to top.

Also need more commands to review the mails that have already been read.
Review as in list them sorted by date or subject,
and select one to read using the above mechanism.
And more commands to create filters that send messages into folders
based on subject and from and to addresses.
Yes I know - one step at a time.    :)

Karl Dahlke
_______________________________________________
Edbrowse-dev mailing list
[email protected]
http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev

Reply via email to