search

php / pecl-mail-imap

An extension to operate with the IMAP protocol, as well as the NNTP, POP3, and local mailbox access methods.
Other
8 stars 2 forks source link

Consider vendoring c-client #3

Closed NattyNarwhal closed 1 month ago

NattyNarwhal commented 11 months ago

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:

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 commented 11 months ago

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

derickr commented 11 months ago

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

macintoshplus commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 7 months ago

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:

vs.

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 commented 7 months ago

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 commented 7 months ago

@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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

[...] 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 commented 7 months ago

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 commented 7 months ago

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.

NattyNarwhal commented 7 months ago

I talked with Chappa and he did clear up some stuff; namely, Panda IMAP was a commercial product and only open sourced after Crispin's death, which explains why distros didn't pick it up then. Alpine-the-client merged in the Panda changes when that happened.

Uzume commented 7 months ago

[...]Panda IMAP was a commercial product and only open sourced after Crispin's death[...]

Yes, that is why the archived version of the Panda programming IMAP website does not provide download links and instead says: "Panda IMAP is available by donation." This is also why the available open source version has no apparent revision history: just the one final "imap-2010" version. We have to thank @jonabbey for publishing it here at GitHub under the open source license on 2013-04-13 (and the few subsequent updates he made after).

If you go through the archived versions of the Panda IMAP home page at the Wayback Machine one can see "update" dates of:

The final "update" seems to be 2012-02-21 but that is listed on a different changes page which also promises coming changes for a future "imap-2011".

As far as I can tell, any other revision history including source code seems to be lost to the sands of time.

Uzume commented 7 months ago

If this PHP IMAP extension is potentially looking at drastic changes, other potential options are a pure PHP implementation or binding to a different IMAP client library than c-client, e.g., src/lib-imap-client from dovecot/core (but I have no idea what that entails; I do notice there seems to be a separate lib-auth-client) which seems to be under an MIT license.

I still think moving to alpine-imap is the most straightforward approach towards a useful and maintained future.

cmb69 commented 4 months ago

@macintoshplus, indeed the sources for the Windows builds are in https://github.com/winlibs/imap, and the build routine is in https://github.com/winlibs/winlib-builder. Binaries can be found on https://downloads.php.net/~windows/php-sdk/deps/ (look for c-client-2007f-1-*.zip in the respective folders).

cmb69 commented 2 months ago

In my opinion, it makes no sense to try to revive this extension; instead we should just focus on minimal maintenance (i.e. fixing incompatibilities with new PHP versions, and maybe fix a bug occassionally). And users should switch to some PHP implementation as soon as possible (https://github.com/barbushin/php-imap seems quite popular); performance shouldn't really matter anyway.

derickr commented 1 month ago

I don't think we should do this, as that would mean we sort of commit to maintaining this extension, which is not what we decided on by unbundling it.

Uzume commented 1 month ago

I don't think we should do this, as that would mean we sort of commit to maintaining this extension, which is not what we decided on by unbundling it.

@derickr: I agree. This issue requested the vendoring of c-client based on uw-imap not being maintained. I do not think we want to vendor and maintain that source code, especially when c-client is definitely currently maintained as part of imap in alpine (the email client, etc.). A separate issue/pull request can be filed if someone wants to move to that instead (which is also questionable based on the status of this extension and the availability of similar libraries/extensions).

It should be noted the unbundling decision was also based upon the premise that c-client is unmaintained but that is untrue. It is only unmaintained at the older locations and is still maintained as a part of Alpine (the email client, etc.) so an argument could be made to undo the unbundling based on its original premise being flawed.