Consider vendoring c-client

[NattyNarwhal]

uw-imap is not maintained beyond patches that i.e. Alpine and Debian have to keep it building on modern systems. It may be good to centralize the effort to keep it on life support, be it in a separate project, or as part of this PHP extension.

(This is not a demand. I've been looking into trying to do this myself - mostly just to merge the patchsets and provide a place to land new ones. And clean up the code, if I get around to that, since at minimum the build system is gross.)

Alternatively, rewriting the extension to use a separate library or as a userland library presenting the same interface might be a better idea.

FWIW, at least in Debian, the only dependents of c-client outside of PHP are:

• uw-mailutils (the binaries that go with c-client, probably unmaintained)
• mailsync (seems sporadically maintained)
• prayer (dropped in bookworm)
• asterisk-voicemail-imapstorage (dropped in bookworm)

So, I'm not sure if doing a separate project just for mailutils or mailsync users might be wise if someone does want to maintain c-client.

[remicollet]

I'm +1 to bundle the needed parts of uw-imap (libc-client) sources here to avoid relying on a dead project.

[derickr]

I'm not in a favour, as that means we're on the hook for supporting it.

[macintoshplus]

I have the same question to find a version of c-client capable of compiling on Windows. Having an external repository for the extension might be better.

I don't know where to find the sources that allowed the generation of the library present in the PHP 8.3 SDK. Do you know where the sources are?

I suspect that the library will no longer be available in the PHP 8.4 SDK or later.

The extension compiles well on Windows and is available here:
https://phpext.phptools.online/extension/mail/imap-425

[NattyNarwhal]

The extension is in the PHP source, but will be removed some time before 8.4 comes out. Obviously, it'll be in the old versions.

There is a horrible makefile for Windows in the uw-imap source; I'm not sure how exactly the Windows ones were built.

[macintoshplus]

I had to ask for help to find it. The source code for the Windows libraries for the Windows SDK are in a separate organization called winlibs.

So I found the source code of the library:
https://github.com/winlibs/imap

[NattyNarwhal]

I got surprisingly far hacking up uw-imap to use CMake over here: https://github.com/NattyNarwhal/imap

Still need to do Windows support amongst other things (that codebase is very much decrepit 90s C...).

[Uzume]

Why is this extension still using the mostly unmaintained uw-imap? As a binding of c-client, this extension seems to only support client IMAP, etc. and will not help one develop an IMAP server in PHP. This is completely fine but it also means it does not need the server parts of uw-imap.

@NattyNarwhal mentions Alpine at the beginning of this issue. I do not understand why this extension does not move to that. It appears to also support Windows as there are Windows binaries of Alpine linked on its website. Also the difference in development and maintenance is huge. Compare:

• https://github.com/uw-imap/imap/commits/master/src/c-client

vs.

• https://repo.or.cz/alpine.git/history/HEAD:/imap/src/c-client

You will also notice that Alpine c-client library also supports a number of new features, e.g., OAuth2 authentication, etc.

If we want maintained code and we do not want to maintain it ourselves, I believe Alpine c-client is the way to go (unless we want to move to an entirely different IMAP implementation but it would likely be hard to maintain the API for PHP clients of this extension).

I am not sure if this extension will work with the Alpine c-client library "out of the box" but I believe porting to it should seriously be considered over any consideration for vendoring c-client locally here.

[NattyNarwhal]

I was talking about Alpine Linux's packaging; I actually didn't know Alpine the mail client actually had a vendored and maintained fork of UW IMAP. My fork of c-client was mostly just massively cleaning up platform support and build system stuff, so it's probably possible to combine that work with Alpine's c-client fork. Maybe the effort between the two projects can be shared as well.

[Uzume]

@NattyNarwhal: Oh, my mistake. I thought you were referring the mail client that was also developed at UW not the unrelated Linux distribution by the confusingly same name.

I looked at the Alpine (mail client) code a bit more and I think you are right, they are maintaining a complete fork of UW IMAP (there even seems to be the server code in there, etc.).

Despite touting themselves as an email client, the top of their README says:

Alpine/Pico/Pilot/Web Alpine/Imapd Distribution

I am sure you notice the "Imapd" in there so it seems to be a complete fork of UW IMAP in addition to the email client application, etc..

If there are things you have done to your copy that they have not already done, I bet they would be willing take patches/PRs.

Alpine upgraded to panda-imap (a fork of UW IMAP by Mark Crispin the original author of c-client) at Alpine 2.19.1 (2013-11-02) and it is mentioned in the release notes on their website for Alpine 2.20.

[NattyNarwhal]

They're using the original or their own build system, so I don't know how interested they would be in my changes. However, I'll look into integrating the changes they made, and perhaps reaching out and see if they want to collaborate on unvendoring it since there's other users of the library.

[Uzume]

Even without considering alpine-imap one needs to recall that c-client is a creation of Mark Crispin while at Stanford before he went to UW (and thus it predates uw-imap; you can see this in NOTICE from uw-imap). In that light, it makes sense to at least consider panda-imap since it was a fork of uw-imap by Crispin, himself after UW stopped hosting uw-imap. See http://panda.com/imap/ archived at Wayback Machine 2012-07-16.

However, panda-imap stopped in 2010 (and Crispin died in 2012) and since Alpine incorporates it at Alpine Alpine 2.19.1 (2013-11-02) and continues to develop and maintain its alpine-imap, I believe that is the best way to go.

[NattyNarwhal]

I didn't even know Crispin maintained a post-UW fork of it. The distros packaging it seemed unaware too; they had their own patchsets on top of the last 2007e version. This is pretty tangled up.

[Uzume]

[...] This is pretty tangled up.

@NattyNarwhal: Agreed. And that is why I do not recommend sifting through all that noise when it has obviously been consistently maintained by Crispin (from 1987 to 2010 at Stanford, UW and Panda), briefly by @jonabbey (from 2013-04-11 to 2013-06-21) and later Chappa (Alpine 2.19.1+ since 2013-11-02).

I honestly don't really understand why this PHP extension seems to be based off the fork of uw-imap by @senseisimple (only 16 commits all on 2019-01-03).

[NattyNarwhal]

There's no vendored library, so this extension isn't using that fork unless someone's building with that version of c-client. Again, distros seem to have their own patchset (and of those I think mostly based on Debian's?) instead of using that.

I'll probably poke Chappa sometime to see how dependent the Alpine vendored c-client is on Alpine itself, and what he might be interested in doing.

[Uzume]

Yes, it would probably be a good thing to get Debian off of uw-imap and on to alpine-imap or at least panda-imap. Debian already has an alpine source package with a few packages derived from it. It just needs to subsume the packages from the uw-imap source package.