Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80277
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain beberlei.de from 74.125.82.51 cause and error)
MIME-Version: 1.0
In-Reply-To: <54AE7340.6080708@fedoraproject.org>
References: <CAEPJdu=2oWiSCQOTkO1g5QDs4NrJwd5H14Jks17qrNu7-eQNVg@mail.gmail.com>
	<54AE7340.6080708@fedoraproject.org>
Date: Thu, 8 Jan 2015 13:38:04 +0100
Message-ID: <CAEPJdu=jLHTmHsWjV8bSAtj9Pa+R_z5ZY3RQf85tM4DStQ7YZw@mail.gmail.com>
To: Remi Collet <remi@fedoraproject.org>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7ba977a4c2bfc0050c234f37
Subject: Re: [PHP-DEV] [RFC] Extension Prepend Files
From: kontakt@beberlei.de (Benjamin Eberlei)

--047d7ba977a4c2bfc0050c234f37
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 8, 2015 at 1:08 PM, Remi Collet <remi@fedoraproject.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Le 04/01/2015 12:52, Benjamin Eberlei a =C3=A9crit :
>
> > https://wiki.php.net/rfc/extension_prepend_files
>
> Sorry but definitively seems a bad idea.
>
>
> If you want a pure-php library, provide as one.
>
> If this library need an extension, just describe this in the metadata
> (pecl, composer, ...)
>
> Ex:
> - - twig extension (of the C extension is optional in this case)
> - - xhprof (or its fork)
>

> Having a "huge" piece of code included in "each" request will be a
> nightmare.
>

This argument is irrelevant to the RFCs goal in my opinion.

1. This RFC is about making it possible "somehow" to bundle PHP code with
extensions that is *required* to make the extension work in a sane way for
the end-user.

2. The size of that code or the performance impact is irrelevant imho.
Users of extensions with this functionality can decide how this affects
their server performance and if they are ok with that.

3. Code that is *optional* can still be a Composer/PEAR/anything library.

4. Everything CAN be misused. You can already write an extension that
includes LOTS of code in RINIT. This RFC is only about defining a sane
process for allowing this, instead of a hack that it is now.

Examples of good use-cases for this feature:

1. Low-Level MongoDB connection code in C, userland OOP API in PHP.
2. Low-Level Crypto code, simplified PHP functions (think ext/hash +
ext/password)
3. Database Vendor Extensions in C + common DB abstraction in PHP (PDO2).
4. Low-Level Date handling, high level PHP code

This RFC tries to solve the current approach to extensions:

1. Writing everything in C, which is difficult to maintain and more prone
to nasty bugs (segfaults, memory leaks).
2. Requiring a PHP library to be installed, which is makes installation
complicated as its not supported by PHPs extension tooling in a
straightforward way right now.

I should rewrite the RFC and remove the implementation details, because
essentially the solution could also be tooling based (vs code based).


> Yes, PHP library can be managed per host/dir/app/whatever
> While extension are enable for all the SAPI.
>
> Seems you are trying to solve a "downstream" issue, not a PHP one.
>
>
>
> Remi.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlSuc0AACgkQYUppBSnxahiKxQCgpTnfu8Jpjz3nauIRCZGZHvi9
> asAAniYb0b8m7Sn9I5MVooxssD5a2oS1
> =3DdkkN
> -----END PGP SIGNATURE-----
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--047d7ba977a4c2bfc0050c234f37--