[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Would a --field option to frm be generally useful?
From: |
Alain Magloire |
Subject: |
Re: Would a --field option to frm be generally useful? |
Date: |
Mon, 12 Mar 2001 23:14:15 -0500 (EST) |
Bonjour
> A few things in this diff:
>
> 1 - I changed it to only print subject if get_header(SUBJECT)
> returned success, otherwise I assume it would print the stack.
Ha yes, thanks.
> 2 - I corrected a tiny typo in the usage message.
>
> 3 - And I added an option -f,--field that prints the named field
> in the mailbox, and nothing else. Don't know if that's generally
> useful, or if the API of frm is supposed to be some particular
> way to be compatible with some other frm.
Compatible yes but not restricted to.
frm, readmsg, printmail, etc ... are very usefull, a friend of mine
wrote a "shellmail" that spawned those tools and use it as his email reader.
> Also, it wouls seem to me that I should be able to provide a url
> as the mailbox, but neither file://home/sam/Mail/Sent nor
> file:///home/sam/Mail/Sent seemed to work for me. I didn't have
> time to look for why, yet. Should they work?
Yes, I simply forget to "register" in the "registrar" (hello dinglis ;-)
the "file:" URL. see in frm.c :
/* register the formats. */
{
list_t bookie;
registrar_get_list (&bookie);
list_append (bookie, mbox_record);
list_append (bookie, path_record);
list_append (bookie, pop_record);
list_append (bookie, imap_record);
}
This means that I have registered:
mbox_record "mbox:" (Unix format)
imap_record "imap:" (Imap mailbox)
pop_record "pop:" (POP mailbox)
if you want "file:" add it to the list :
{
...
list_append (bookie, file_record);
}
and you will be able to do :
# MAIL=file:///home/sam/Mail/Sent ./frm
# ./frm file:/home/sam/Mail/Sent
And you will ask, why all this complexity and heavy artillerie?
The ideas behind it are :
- not to link with the clients things that it does not need.
- Allow runtime extension, i.e. possibility of a client at runtime
to support new mailboxes. It's the component approach, or the
COM or CORBA approach. The mailbox library maintains a global
linked list :
{
list_t bookie;
registrar_get_list (&bookie);
...
You can add to it(the link list) concrete implementation of mailboxes,
when time comes to choose a concrete mailbox that implementing
a specific URL (pop:, imap:, file: etc ...) it iterates to
the link list to find a match(strcasecmp()) When one is found
it creates it and return the structure.
...
list_append (bookie, path_record);
list_append (bookie, pop_record);
list_append (bookie, imap_record);
}
If you need only mailbox, you should be able to :
gcc -o my_app -lmailbox -lpop
of if you prefer to do that at Runtime :
gcc -o my_app -lmailbox
and in the code :
{
list_t bookie;
registrar_get_list (&bookie);
handle = dlopen ("libpop.so", RTLD_LAZY);
pop_record = dlsym(handle, "pop_record");
list_append (bookie, pop_record);
}
Or if you have some new funky mailbox that you implemented :
dlopen ("libmailencrypt_ssl.so", ...);
ssl_record = dlsym (handle, "ssl_record");
....
list_append (list, ssl_record);
Well that is the general idea, but we are not here yet, I have to get
libtool to generate shared libs for each type: pop.so, imap.so, mh.so
etc ... Work in progress.
--
alain