Hi
2012/4/27 Jille Timmermans :
> Hi,
>
> I suggest we add a function boolval(). It simply converts the given argument
> to a boolean, like strval(), intval() and floatval(). I already have an
> implementation ready[1].
>
> Why?
> * It is missing in the current list of *val()-functions and people
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.
--
S
On Fri, Apr 27, 2012 at 11:00 PM, Derick Rethans wrote:
> 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'
On Fri, 27 Apr 2012, Nikita Popov wrote:
> On Fri, Apr 27, 2012 at 3:49 PM, Pierre Joye 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 an
On Fri, 27 Apr 2012 15:49:03 +0200, Pierre Joye
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
hi,
On Fri, Apr 27, 2012 at 9:41 PM, Richard Lynch wrote:
> 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 ,m
hi Nikita.,
On Fri, Apr 27, 2012 at 10:23 PM, Nikita Popov
wrote:
> On Fri, Apr 27, 2012 at 3:49 PM, Pierre Joye 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 alr
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 poin
On Fri, Apr 27, 2012 at 3:49 PM, Pierre Joye 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 usag
On 27-04-12 22:19, Kris Craig wrote:
On Fri, Apr 27, 2012 at 1:14 PM, Jille Timmermans https://github.com/php/php-__src/pull/60
Do you have wiki access? If so, please post an RFC for this! You'd
have my vote. =)
I don't. If anyone can give it to me I will post an RFC :)
-- Jille
--
PHP In
On Fri, Apr 27, 2012 at 1:14 PM, Jille Timmermans wrote:
> Hi,
>
> I suggest we add a function boolval(). It simply converts the given
> argument to a boolean, like strval(), intval() and floatval(). I already
> have an implementation ready[1].
>
> Why?
> * It is missing in the current list of *v
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
Hi,
I suggest we add a function boolval(). It simply converts the given
argument to a boolean, like strval(), intval() and floatval(). I already
have an implementation ready[1].
Why?
* It is missing in the current list of *val()-functions and people
expect it to exist. I'd say it is an incon
On Fri, April 27, 2012 1:51 pm, Pierre Joye wrote:
> hi!
>
> On Fri, Apr 27, 2012 at 8:40 PM, Stas Malyshev
> 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
hi!
On Fri, Apr 27, 2012 at 8:40 PM, Stas Malyshev 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/
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 ex
hi,
On Fri, Apr 27, 2012 at 7:47 PM, Stas Malyshev wrote:
> 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 up
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 API
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 t
You might be interested by zend_call_method_with_[XXX]_params() as
well http://lxr.php.net/xref/PHP_5_3/Zend/zend_interfaces.h
Julien.Pauli
On Fri, Apr 27, 2012 at 8:51 AM, Laruence wrote:
> Hi:
> you can refer to zif_call_user_func, which could be find at
> http://lxr.php.net/opengrok/xref/PHP
20 matches
Mail list logo
