hi!
Before I go with a RFC and all that, I would like to check the current
feeling about killing ext/imap. The c-client project is dead since
quite some time already. I do not see any viable alternative
(applicable to server side usages) and it would be very hard to
maintain the same APIs, given the little mess in the imap's API.
There are also plenty of very good PHP implementation out there.
Roundcube being my favourite, zeta components of the Zend Frameworks
being two other.
What are your thoughts about this drop?
Links:
http://incubator.apache.org/zetacomponents
http://framework.zend.com/
http://roundcube.net/
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi!
Before I go with a RFC and all that, I would like to check the current
feeling about killing ext/imap. The c-client project is dead since
quite some time already. I do not see any viable alternative
(applicable to server side usages) and it would be very hard to
maintain the same APIs, given the little mess in the imap's API.
Whatever mess it is, tons of code is using it, and isn't going to move
to Zend Framework any time soon (and roundcube is GPL which means it's
unusable for many projects). So dropping it means these projects will
never be able to upgrade.
Now, what would such move give us? Is there any problem with imap now?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
hi,
Whatever mess it is, tons of code is using it, and isn't going to move
to Zend Framework any time soon (and roundcube is GPL which means it's
unusable for many projects). So dropping it means these projects will
never be able to upgrade.
As I said there are many very good alternatives, BSD-like too.
Now, what would such move give us? Is there any problem with imap now?
Yes, many (see the bugs DB). And c-client is as dead as msql.
What does it bring to us? Less work, less worry, less issues, give a
clear signal to the projects to migrate. Also keep in mind that we are
talking about 2015 here as 5.4 still has it.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi!
As I said there are many very good alternatives, BSD-like too.
Alternative means rewriting all the code. On top of framework previously
not used in the project, with different APIs, different approach to
IMAP, etc. This is a large piece of work, for many projects - totally
unnecessary as ext/imap work for them right now.
That provided the person in question actually owns the code, not just
runs the app. In the latter case he has no options to upgrade at all.
Yes, many (see the bugs DB). And c-client is as dead as msql.
Bug DB is full of bugs for everything, not a reason to drop imap. As for
"less work", I don't see how much less work can be done on imap that is
done now. If it still works for people, why remove it? I see no reason
to do this.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
hi!
Alternative means rewriting all the code. On top of framework previously
not used in the project, with different APIs, different approach to
IMAP, etc. This is a large piece of work, for many projects - totally
unnecessary as ext/imap work for them right now.
I think you over estimate the complexity to move something to a clean,
maintained, user friendly API from a over complex, buggy and
unmaintained extension and library (which can kill requests under
certain circumstances too).
That provided the person in question actually owns the code, not just
runs the app. In the latter case he has no options to upgrade at all.
Again, 2015! That's not now, not tomorrow but 2015!
Yes, many (see the bugs DB). And c-client is as dead as msql.
Bug DB is full of bugs for everything, not a reason to drop imap. As for
"less work", I don't see how much less work can be done on imap that is
done now. If it still works for people, why remove it? I see no reason
to do this.
if totally dead and not secure c-client is not a good reason, then I
have no idea what a good reason is :), and again, we are saying: "Heh,
I know you are busy like hell, but we are going to kill imap support
in 2015, and some distros will maintain 5.4 for a couple of years
longer too, so you should have enough time to migrate the little code
taking care of imap".
And why do I say "little code"? Because anyone making anything serious
(except basic reading ops) with imap already migrated to alternatives
or wrote its own implementation.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
hi!
On Fri, Apr 27, 2012 at 8:40 PM, Stas Malyshev
smalyshev@sugarcrm.com wrote:Alternative means rewriting all the code. On top of framework
previously
not used in the project, with different APIs, different approach to
IMAP, etc. This is a large piece of work, for many projects -
totally
unnecessary as ext/imap work for them right now.I think you over estimate the complexity to move something to a clean,
maintained, user friendly API from a over complex, buggy and
unmaintained extension and library (which can kill requests under
certain circumstances too).
I think you are over-estimating my bandwidth to take on such a task. :-)
That provided the person in question actually owns the code, not
just
runs the app. In the latter case he has no options to upgrade at
all.Again, 2015! That's not now, not tomorrow but 2015!
I have an imap script running server-side to filter my email and knock
out a whole bunch of spam that SpamAssasin doesn't catch.
It's been running in a cron job since at least July 15, 2004
That's just the earliest mod-time file I can find in the directory...
It's been running longer than that, actually.
I set it up when Eudora was taking too long to download my email.
And Eudora was free.
And ad-free.
So that's probably pre-2003, if I'm reading Wikipedia correctly.
I add a new folder and edit the script or set up an alias and edit the
script or find a new annoying pattern and edit the script...
It's currently at 1065 lines of code, most of which are mailbox
filtering or patterns to kill spam.
It's been working fine for 8 years.
I don't really care if it dies in any given run.
It's going to run again in 10 minutes anyway.
I dunno what 8 years time 10 minutes is, but that's an awful lot of
times it worked just fine.
I don't have time to change it, it's running all on an internal
network at my webhost, so security is not a real concern.
I'd have to plead "No"
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
Hi Richard,
I've heard of a lot of people with little scripts running around, that
need really need magic quotes enabled. (j/k)
All joking aside I know that probably having something running fine
for 8+ years is great. Congrats on that achievement!
There are reasons to evolve things to the point where older code
really can't remain compatible - obvious disclaimer: I don't use
ext/imap I'm biased when it doesn't hurt me... - but I think that
security or lack of maintenance might be the two crucial points that
might culminate in that decision when thinking long term.
That's not to say you shouldn't voice your opinions, specially when
you're dependant on the ext, be it for a larger project, or for a
personal geeky filter I congratulated you on earlier.
But if the ext is no longer being maintained, even if working properly
for the time being, there might be a point to marking it deprecated,
with proper directions for alternatives/migrations.
The problem is not today, or these past 8+ years it's been working
wonderfully for you; but what happens when you're keeping the ext
active [i.e. not deprecated], and problems come around some time from
now. Since it's unmaintained, there might be a problem when there's no
one wanting to fix it...
You should probably find confort in also having a better code with a
more robust API, even though you might be forced into touching
something you havent for 8+ years (we all know how that feels like).
If not, then at least consider this should be marked as deprecated
(even without a due date for complete removal), just for the sake of
no longer being maintained!
~ Daniel Macedo
hi,
I have an imap script running server-side to filter my email and knock
out a whole bunch of spam that SpamAssasin doesn't catch.
Wrong tool for this task, but that's another discussion. Also as I
said, if all you need is to read ,mails, it takes 5mins to do it with
any of the previously libraries. They even have very nice to implement
filters in a better way than what you could with ext/imap.
I don't have time to change it, it's running all on an internal
network at my webhost, so security is not a real concern.I'd have to plead "No"
And what prevent you then to keep php 5.4 for the next 10 years as well?
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi!
I think you over estimate the complexity to move something to a clean,
maintained, user friendly API from a over complex, buggy and
unmaintained extension and library (which can kill requests under
certain circumstances too).
No I do not. It doesn't matter if it's maintained or not if the code
works. However friendly and shiny new components are, it is new
development in the application infrastructure, and believe me, I know
how much that costs in dev time, qa time, support time, etc., etc. If
you ever did such thing, you must know it too.
Again, 2015! That's not now, not tomorrow but 2015!
5.5 is planned to be released next year, isn't it? Users of imap will
not be able to use it. I see no reason to set up both them and 5.5 for
this fail.
if totally dead and not secure c-client is not a good reason, then I
have no idea what a good reason is :), and again, we are saying: "Heh,
Good reason would be extension broken and nobody willing to fix it, or
presence of the superior alternative with easy migration path. imap
works for its users just fine, and alternatives require installing
frameworks with substantially different APIs. So what? We have bugs in
many extensions. It is sad that maintainers do not fix them, but so is
the nature of the volonteer project. If the extension still works, I see
no reason to remove it.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
hi!
Before I go with a RFC and all that, I would like to check the current
feeling about killing ext/imap. The c-client project is dead since
quite some time already. I do not see any viable alternative
(applicable to server side usages) and it would be very hard to
maintain the same APIs, given the little mess in the imap's API.
A question not directly related to the rest of the discussion:
"Killing ext/imap" just means that it is not shipped by default
anymore right? It will still be available via pecl, so people who want
to use it, still can, right?
Nikita
hi Nikita.,
On Fri, Apr 27, 2012 at 10:23 PM, Nikita Popov
nikita.ppv@googlemail.com wrote:
hi!
Before I go with a RFC and all that, I would like to check the current
feeling about killing ext/imap. The c-client project is dead since
quite some time already. I do not see any viable alternative
(applicable to server side usages) and it would be very hard to
maintain the same APIs, given the little mess in the imap's API.A question not directly related to the rest of the discussion:
"Killing ext/imap" just means that it is not shipped by default
anymore right? It will still be available via pecl, so people who want
to use it, still can, right?
Right, and distros will release it forever too. We only say that we do
not support it anymore, just like we did with sqlite (which has zero
bugs and was widely used and did not have easy migration path for the
databases).
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
hi!
Before I go with a RFC and all that, I would like to check the current
feeling about killing ext/imap. The c-client project is dead since
quite some time already. I do not see any viable alternative
(applicable to server side usages) and it would be very hard to
maintain the same APIs, given the little mess in the imap's API.A question not directly related to the rest of the discussion:
"Killing ext/imap" just means that it is not shipped by default
anymore right? It will still be available via pecl, so people who want
to use it, still can, right?
Sigh. That works for people that control their environment. It doesn't
work for the pletoria of cases where you have to rely on the hosters.
Most hosters would never install anything from PECL.
As far as I know, ext/imap works, it's not beautiful, but it works. So
no need to remove it.
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Sigh. That works for people that control their environment. It doesn't
work for the pletoria of cases where you have to rely on the hosters.
Most hosters would never install anything from PECL.As far as I know, ext/imap works, it's not beautiful, but it works. So
no need to remove it.
May I ask why you agreed to move sqlite away? That is a very close
situation (well, better as sqlite library status was way better than
current c-client).
Not trying to troll, but trying hard to figure out your reasoning here.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi!
May I ask why you agreed to move sqlite away? That is a very close
situation (well, better as sqlite library status was way better than
current c-client).
There's sqlite3, but nothing like this for imap. If there were another
superior imap extension it would be different business.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Stas Malyshev wrote:
May I ask why you agreed to move sqlite away? That is a very close
situation (well, better as sqlite library status was way better than
current c-client).
There's sqlite3, but nothing like this for imap. If there were another
superior imap extension it would be different business.
That I think is exactly the point here?
While imap is not being maintained, there has been no pressure to produce an
alternative simply because it does a job. YES there are problems with it which
nobody has stepped up to the plate to address which is the real problem, and
changes to PHP do cause problems when they require work in all the extensions to
maintain compatibility, but in the absence of an alternative is there any option
but to leave it available.
What are the alternatives to it that can be bundled into a base distribution?
Is this another case where a switch to a more generally distributed model should
be the way forward. ALL extensions are optional and only need to be rebuilt when
there are core interface changes that require that, rather than every extension
having to be recompiled with every version number change?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
hi,
Hi!
May I ask why you agreed to move sqlite away? That is a very close
situation (well, better as sqlite library status was way better than
current c-client).There's sqlite3, but nothing like this for imap. If there were another
superior imap extension it would be different business.
There is no way to migrate sqlite databases to sqlite3 without doing
it manually. So this point is totally irrelevant.
Also imap will be available via pecl, no issue. Shared hosters won't
update before 2016 anyway, for the 1st ones.
I think we cover the main points.
There are no really new possible arguments. I will write the RFC early
next week and then ask for vote 2 weeks later. Thanks for your
feedback.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
hi,
On Sat, Apr 28, 2012 at 3:15 AM, Stas Malyshev smalyshev@sugarcrm.com
wrote:Hi!
May I ask why you agreed to move sqlite away? That is a very close
situation (well, better as sqlite library status was way better than
current c-client).There's sqlite3, but nothing like this for imap. If there were another
superior imap extension it would be different business.There is no way to migrate sqlite databases to sqlite3 without doing
it manually. So this point is totally irrelevant.Also imap will be available via pecl, no issue. Shared hosters won't
update before 2016 anyway, for the 1st ones.I think we cover the main points.
There are no really new possible arguments. I will write the RFC early
next week and then ask for vote 2 weeks later. Thanks for your
feedback.Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
did you ever sent that mail?
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
On Fri, 27 Apr 2012 15:49:03 +0200, Pierre Joye pierre.php@gmail.com
wrote:
Before I go with a RFC and all that, I would like to check the current
feeling about killing ext/imap. The c-client project is dead since
quite some time already. I do not see any viable alternative
(applicable to server side usages) and it would be very hard to
maintain the same APIs, given the little mess in the imap's API.There are also plenty of very good PHP implementation out there.
Roundcube being my favourite, zeta components of the Zend Frameworks
being two other.What are your thoughts about this drop?
Since the library is not maintained anymore, this is an obvious candidate
to move to PECL -- same case as sqlite.
But then PHP will be further from Zawinski's law of software envelopment,
which is a cause for concern :)
[1]
http://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski.27s_law_of_software_envelopment
--
Gustavo Lopes
Le 27/04/2012 15:49, Pierre Joye a écrit :
hi!
Before I go with a RFC and all that, I would like to check the current
feeling about killing ext/imap. The c-client project is dead since
quite some time already. I do not see any viable alternative
(applicable to server side usages) and it would be very hard to
maintain the same APIs, given the little mess in the imap's API.There are also plenty of very good PHP implementation out there.
Roundcube being my favourite, zeta components of the Zend Frameworks
being two other.What are your thoughts about this drop?
FYI php-imap extension is no more available in RHEL-7 (beta) because of
c-client.
So I will agree a move to pecl for this extension.
Remi.
Links:
http://incubator.apache.org/zetacomponents
http://framework.zend.com/
http://roundcube.net/Cheers,