Re: Hydrant C++

[Jakob 'sparky' Kaivo]

"Alain Magloire" <address@hidden> writes:

> > on  one vision of what is a mailbox and how to access it.  So
> > the object "mailbox_t" and the object "message_t" are just empty
> > or virtual class (in our case pointers to functions in a structure) that
> > the different format implements, So the POP will implement the
> > int (*read)() function of message_t differenty then the int *(read)()
> > function of IMAP.  In the former case a "RETR %d\r\n" is generate and the
> > later a "tag FETCH % BODY[]\r\n" is send.
> 
> Should have pointed that a mailbox_t/message_t do not have to be EMAILs
> for example we could have a slashdot mailboxes.
> 
> {
>       mailbox_create (&mbox, "slashdot://www.slashot.org");
> ....
> }

Interestingly, GNUS (the Emacs news/mail client) has this. It might be
worth looking into/translating from Lisp...

> or the messages maybe sitting on an SQL databases;
> 
> {
>       mailbox_create (&mbox, "sql://database.com");
> ....
> }
> 
> or maybe the emails or only accessibe via hotmail but you don't
> like the web interface and rather use hydrant funky layout.
> 
> {
>       mailbox_create (&mbox, "hotmail://address@hidden");
> ....
> }

Also in GNUS.

> Once the backend is implemented suddenly those little programs
> take a new meaning.
> 
> # MAIL=slashot://www.slashdot.org ./from
> 
> For example, for Elm to take advantage of this will require some
> serious code change. Pine OTO can get away with it since it uses
> the c-client as the backend.  Mutt I do not know.

Actually, I was thinking about this the other day. Using MAIL in this
fashion for anything other than a local file basically breaks any
non-libmailbox mailer. Now, while this can be seen as a Good Thing
(<insidious>you must use only libmailbox mailers, or we will send man
in black suits to your house</insidious>), it might be wise to provide
an alternate way of specifying the default mailbox. Either another
environment variable (MAILBOX?) or an .rc file.

-- sparky