Re: Mail-IMAPClient-3.22 just released on CPAN

["Phil Pearl (Lobbes)" <phil at zimbra dot com>]

[taking this conversation to the imapsync list]
Hi Gilles,

Sorry for the delay in responding...

> >> Just an unbelievable decision about Socket() function. 
> > Obviously, I wasn't involved with that.
> 
> I know and I'm happy you took the beast, because:
> - You use Mail-IMAPClient and (really) want it to work.
> - You take care of what I say.

I'm definitely trying to keep it moving along and hopefully we can
continue to collaborate on it along with imapsync.  I've used it
quite extensively over the past year migrating over 1.2 million 
mailboxes.  I've still got a few big ideas for imapsync if you're
up for a few (handling case insensitivity of folders on the
destination for example).
 
> > my impression was that RawSocket() basically is the equivalent
> > of the old Socket().  Is that not the case?
> 
> Yes.
> Changing the documented and already used API,
> used in so many good programs, is one of the most stupid
> thing a library coder can do...

Agreed, changing the public API was not a good choice and I would
have preferred that Socket remain as it was.

> The solutions are so easy to avoid such breaks:
...
> - Name the new (ugly) Socket with any other name than Socket,
>    there is an infinite number of names to pick up. Better.
>    And fully document it and respect what is documented.

At this point, I not convinced it would be beneficial to go back to
the old name.  What do you think?  Changing things again would break
things for anyone now using the 3.x behavior.  I am happy to discuss
but it doesn't seem like much of a win now that imapsync has already
worked around it.

> > The connect() and login() and Socket() methods are documented...
> I've read them many times when I wrote imapsync.
> For example, the expunge() API...
[... discussion of shortcomings/flaws/bugs in earlier 3.x removed ...]

> > The biggest issue I see is that the docs are *so* wordy that it's
> > hard to follow the fact that new can call connect which...
> 
> I prefer you respect the previous API which was simple and clearly
> documented.   Socket() was just an access- get or set- to the socket.
> A good name for a good purpose. SSL made easy, TLS made easy,
> XXX made eady.

My goal is to respect the API, I'm willing to discuss reverting to
the 2.x documented behavior but that would probably mean we'd have
to bump the version to 4.x I think and we'd be causing pain for anyone
that wrote to the documented 3.x behavior (in particular Socket -- not
sure if there are any other major changes off the top of my head).

> Of course, you can add any new functions and document them,
> I will respect that.

Great, my hope is that eventually we can git rid of all the copied code
you have in imapsync from Mail::IMAPClient.  And ideally you (and others)
can use the library without having to work around any issues.  I think
we've come a long way, but I know you won't be able to do that completely
without dropping support for Mail::IMAPClient 2.x altogether due to
numerous outstanding bugs in that code.

> In fact, from a user point of view, the good way would be:
> 
> $imap->SSL(1); # The only thing to write to be SSL
> $imap->TLS(1), # The only thing to write to be TLS

With the latest (3.22) release, if you specify Ssl => 1 OR Starttls => 1
to new() then it should do the right thing.  Also true if you do
$imap->Ssl(1) OR $imap->Starttls(1) before connect/login so we are
close to what you want I think.  I believe Starttls is a better name
due to the fact that it maps to actual IMAP command that we want to
use (the method that implements this is starttls() right now).

> May be we have to think more about the TLS API since
> it's a "can do?" thing.

Is there something more/missing from this discussion?  Are there
technical concerns?  Or is this more an issue of clearly naming the
attrs/methods?

I would like you to be able to take advantage of starttls in
Mail::IMAPClient.  FWIW, I think the starttls implementation in
the latest imapsync is slightly broken.  Specifically, this:

  unless($txt =~ /^STARTTLS OK/){
    die "Invalid response for STARTTLS: $txt\n";
  }

The regex on the response should probably similar to just /^OK/
per rfc2595 section 3.1.

> Let's go on on the list, may be other brains can help us.

Sounds good if there's more to discuss, there's certainly no reason
to not keep everyone in the loop and give the community the
opportunity to chime in and help us out.

Phil