Hi Stas! On 30/01/15 20:10, Stanislav Malyshev wrote: > Hi! > >> I’ve rewritten the RFC for pecl_http and hopefully addressed most of the >> things mentioned previously. > > Thank you, Michael, this is much better! > > I would still like to hear more about 2 extensions, especially about > raphf - it seems to be some framework for handling persistent resources, > but it's not clear why we need persistent resources for HTTP module at > all (who keeps HTTP connections open between requests?) and the code in > the example doesn't show any significant logic there - it just basically > wraps curl functions, so I wonder why we need whole new API in core for > that?
API consumers jump into mind f.e. libcurl caches connections itself, so, we're just re-using functionality from curl... with lots of good extras, like cached DNS entries, maybe TLS sessions etc. I also use it in pecl/pq a PostgreSQL client, which seems a perfect fit to me, i.e. any database extension not exposing its database handle as a userland resource should use raphf over zend_list IMO. But Dmitry or any other expert might of course want to say a few better words about zend_list. raphf comes with what's needed to maintain (persistent) service handles within objects. As already explained, we don't need extra refcounting because the objects are already refcounted, but we could need support for handle copy ctors to easily support object cloning, still manually, but without mind boggling code. The benefit of retire and wakeup handlers are already shown in the RFC, additionally, check out the resource factory ops of pecl/pq here: https://github.com/php/pecl-database-pq/blob/master/src/php_pqconn.c#L520-L561 Nothing super-complicated either; though, a copy constructor is not implemented, but that might only be a matter of creating a new connection with information out of PQconninfo(). I guess the brave one could implement similar stuff for zend_list, but all this zend_resource business is useless for interal handles. > About propro - it says that it improves by-reference access to handler > properties, which may be useful but I don't really see how it relates to > HTTP module either - why would you need by-ref access in this context? > Could you give any example of a common code pattern that was impossible > without it but is enabled with it? It doesn't improve it, it yet makes it possible. It's an aid for internal classes that expose properties to userland that actually represent state stored in foreign C struct members, and not in the zvals in the properties table. Hope that sounds sane in any way?! -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
