Re: I'd like to rearrange the stream_t API slightly

[Alain Magloire]

> 
> Allo!

Bonjour,
  under the snow, and freezing rain 8(.

> 
> C'est une semaine de quietude (est'ce que ca francais?) dans la liste, donc
> je propose nous faire quel'que chose un peu differente.
> 

Busy .. Busy
Lots of information to digest in a short period of time.
In the IT industry, the trend is to decrease the time to market
and increase the complexity of projects.  Translate to 
increasing white hair and .. decreasing hair.

> Right now you have to know what kind of stream you want to open
> in two places, when you create the stream (X_stream_create()),
> and when you open the stream (since you have to know what to
> stuff into the char* and int that are all you have to specify
> the stream to open).
> 
> I want to open a STDIO stream, though, so I propose that this would
> work:
> 
> stream_create() creates a stream_t.

Ok.

> stream_open() dissappears.

Hick!  do not like that.

> stream_open_file(stream_t, const char* file, int flag)
>   closes the existing stream (using the existing stream_t.close()),
>   then opens a file and resets up the virtual function pointers
>   to point to file functions

Ok, this is the equivalent of freopen() in stdio.

> 
> stream_open_stdio(stream_t, FILE* f, int flag)
>   closes the existing stream, and opens a new one with a FILE

Cool.

> 
>   (I need stdio streams in my mailer, so it can create a message
>    from stdin, and mailer_send() it).
> 
> It will be easier to accomodate new type of streams that can't get
> the info that's needed to open them stuffed into a char* and an int.
> 

One of the problem with using stdin, is that you can not seek.
You can get away with this if you use a temporary message_t;
message_create (&msg, NULL); But the parsing for mailbox insists
that the stream be seekable.

And it seems to that your trying to use stdin directly, it
may be simpler to use a temporary stream/file to isolate.


> Attached is something I hacked up in half an hour, just to give a
> more concrete example of what I mean. It builds, but won't link.

My 2 cents:
For the stream_open_xxx() calls:
+1
   Should it not be stream_reopen_xx () to insist on the fact
   that those functions will implicitly call stream_close()
   on the original stream?

The nuking of stream_open():
-1
 
> 
> I did a review of the mailbox/*.c code. Every time that I saw
> stream_open() being called, it was known at that point in the code
> what kind of stream was being opened, so it would be easy to make the
> stream_create more generic, and the open more specific.
> 

The original idea was that stream_t is an interface or virtual class,
it does not carry an implementation.  The idea is more enforced
in mailbox2 where there is no stream_create () but rather if
you want an object that has the signature of stream_t
you'll have to get it from a factory:
        stream_file_create (&stream, ...)
        stream_stdio_create (&stream, ...)
        stream_tcp_create (&stream, ...)
        stream_fd_create (&stream, ...)
        stream_buffer_create (&stream, ...)

> I'll make the change and build mailutils against it (if there is no
> objections).

except not to nuke stream_open(), ok.

> Maybe it should be done in mailbox2? But I need it so I can commit the
> mailer I use to test the expanded mailer API (attached, FYI).

mailbox2 goes much further.  In the current scheme, message_t
header_t, body_t, mailbox_t, folder_t etc ...
are all interfaces(in the Java sense of the word).  Meaning they
do not have implementations, the implementations are done by
factories that return an object implementing the interface.

One of the problem with the old mailbox was object like stream_t
carried information and implementation details which 
made it impossible to have simple inheritance and even multiple,...
if suicidal tendencies.

Unfortunately, I did not commit yet my changes in mailbox2/

> I'm going to Sept Iles for a week, but I'll check my mail before
> getting back.
> 

Le coeur a des raisons que la raison ne connait point.

> Bon nuit!
> 
> Sam
> 
> ps1 I've implemented the sendmail mailer as described in the docs
> I committed, next is smtp, but I wanted some comment on how to
> approach this stream issue as I write/test the smtp mailer.

There is a sendmail.c and smtp.c that you may want to look
at first.  The annoying thing with the old code was to
keep the state to be async safe, a real pain.

Is smtp mean the nullmailer that you propose last time?
Using SMTP on port 25(default) to deliver mail to a mailhub,
no MX lookup was involved right?

> 
> ps2 After I've a mailer, I can implement a sieve redirect, finally!
> 

Hourra, our Xmas gift?