Subject: re: coupla' client issues

From: Joel King <[email-masked]>
Date: Wed, 27 Oct 1993 17:19:45 -0600

On Wed, 27 Oct 1993 13:32:53 -0600 Mark Crispin wrote:

> From: Mark Crispin
> Date: Wed, 27 Oct 1993 13:32:53 -0600
> Subject: re: coupla' client issues
> To: [email-masked]
> Cc: [email-masked],
>      c-client Interest List <[email-masked]>
> 
> Mike -
> 
>      Are you saying that mail_create(), mail_delete(), and 
mail_rename() don't
> automatically open an IMAP connection as necessary if a 
MAILSTREAM argument
> isn't supplied?
> 
>      If so, I think you're working with an old or buggy 
version of c-client.

Yes. An earlier version of ECSMail was based on imap2.3 and 
we had to fudge this quite a bit. I had to make sure a 
"sentmail" folder existed in the local (DOS) folder storage 
area in order to open local folders. For remote folders, I 
opened "inbox".

> I think what you want is already there and working in 
current versions; just
> supply a NIL argument for the MAILSTREAM argument.

I have just converted ECSMail to use c-client version 3.0 
and I am pleased that I can now supply NIL stream arguments 
and things will work well. There are just a few problems I 
encountered:
	- A map_open() on a BBOARD with a NIL stream 	  
	  argument requires a "mailbox" in the form:
		{xxxx}*name
	  whereas a map_subscribe_bboard() does not like the 
	  "*" - it add's it's own somewhere along the line, 
	  resulting in the server receiving a SUBSCRIBE on a 
	  bboard with a name like "**name".
	  Is it possible to use a consistent rule here?
	  I have a single routine that formats a "remote" 
	  name before calling any of the mail_* functions.

	- Liberal use of automatic arrays of size MAILTMPLEN 
	  wreaks havoc on the small stack available in a 
	  typical DOS/WINDOWS application. This is 	  
	  expecially severe in imap3.0 since "mail_open()"  
	  is now called with OP_HALFOPEN, sometimes 	  
	  recursively, to get a stream for the above 	  
	  mail_*() operations. Is it possible to allocate 
	  these internally from the heap instead of from the 
	  stack??

	- There were some other problems we encountered with 
	 the dawz driver - mainly du to the fact that we may 
	 have an open local folder (DAWZ) and drag messages 
	 to it. Since DAWZLOCAL keeps an open file handle to 
	 the folder, we had to close and re-open the 	 
	 file anytime messages were added/expunged and	  
	 "dawz_ping()' resulted in a "dawz_parse()". Other 
	 problems we had were some strange read/write 	 
problems which we haven't yet figured out.

		joel
		(Joel King, [email-masked])

---

From: Mark Crispin <[email-masked]>
Date: Thu, 28 Oct 1993 14:05:34 -0700 (PDT)

> 	  name before calling any of the mail_* functions.

The explanation for this is that there is no separate bboard_open().  If there
were, its definition would be:
    MAILSTREAM *bboard_open (MAILSTREAM *oldstream,char *name,long options)
    {
      char tmp[MAILTMPLEN];
      sprintf (tmp,"*%s",name);
      return mail_open (oldstream,tmp,options);
    }

The * is only how c-client internally compresses the separate bboard namespace
into the mail namespace.  You should think of those two namespaces as being
logically separate.

> 	  these internally from the heap instead of from the

I have fixed the egregiously bad stack use with OP_HALFOPEN in the latest (as
yet unreleased) code, I think.

> 	 problems which we haven't yet figured out.

In other words, you're saying that if you append to an open file through
another file handle, you may get this kind of bad behavior?  This sounds like
a bug/misfeature in DOS.  I wonder if dawz can help by detecting a stream
argument in dawz_append() (right now it's only used to pass back a value to
mm_critical()) and seeing if it references the same file as the open stream.
If so, it could then use that file handle.

It would require some main program kludgery to take advantage of it, but it's
hard to imagine anything being worse than what you already have to do.  What
do you think?

Don'cha just love these Fisher-Price operating systems???  ;-)

-- Mark --