(feature request) support for non-stdio plugins (like Hydroxide)

Bill,

judging from the hydroxide webpage, all you need to do is make sure that hydroxide is running properly and then you can tell fetchmail to use that port 1143 to fetch through.

You may need to use the "via" keyword in a fetchmail configuration file (it is not available through the command line interface) to connect to the server.

I do not see a reason to duplicate daemon control features into fetchmail for which more than half a dozen solutions exist already.

Also, if you really must shoot your feet and knees at the same time, fetchmail has a "preconnect" directive, too. See the manual.

Thanks for taking the time to file this bug.

I am not a fetchmail user so I do not know if this is a common use case or if it is used by a few people. Since this is a feature request I am setting the importance to Wishlist and I am adding to our backlog. Let's see if someone with more experience chime in and give us a comprehensive analysis.

Lucas, it is still a support request rather than a feature request since the feature is already there - but unsuitable for the use case. That's why I marked it invalid already. It makes no sense to burden distributions with feature requests because users are unaware of existing features for rare use cases that reveal shortcomings in other tools.

Thanks for the reply Matthias. Based on your comments I'll be also removing it from our backlog.

> Lucas, it is still a support request rather than a feature request since the feature is already there

It's not. You misunderstood the ticket. Your first response mirrors my opening statement, but neglects everything that followed.

The "plugin" option only works with stdio. This ticket is to implement a new capability: to spawn an executable that does *not* talk to fetchmail via standard i/o. My opening statement and your response is the /workaround/ because that capability is lacking.

There is however a complication with the idea of making fetchmail capable of spawing a daemon: when a daemon is executed in the background, it's not necessarily ready to accept traffic instantly. There would be a possible problem if fetchmail were to try to connect to a port before the listener is ready. It's a race condition, and fetchmail would have to be smart about connection reattempts and even have a timeout if the daemon never comes up. So it's perhaps more effort than it's worth. So Hydroxide users will probably have to live with scripting things outside of fetchmail. I think "wontfix - wishlist" is probably a more accurate status, but i suppose it doesn't make much difference.

I was proposing preconnect, not plugin. -> comment #2. There is also postconnect in fetchmail.
You may need to script interfaces with delay and readiness checks. As written before, daemon management is out of fetchmail's scope. Fetchmail is not going to turn into another systemd.

Again, fetchmail does *NOT* need new features here, and this bug tracker is not meant for advice and consultation of complex interfacing rigs with proprietary web services, public API or not.

And if you are inconvenienced by hydroxide's design, feature requests are best filed there - through its primary channels, not secondary ones such as downstream bug trackers.