Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80270
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain beberlei.de from 74.125.82.48 cause and error)
MIME-Version: 1.0
In-Reply-To: <00a201d02ac7$406a4830$c13ed890$@tekwire.net>
References: <CAEPJdu=2oWiSCQOTkO1g5QDs4NrJwd5H14Jks17qrNu7-eQNVg@mail.gmail.com>
	<CAESVnVqAHJujo0anMi7QYhSZeErcfRVAJ=M7oQMG-huk-bxpCg@mail.gmail.com>
	<54AAF98B.4020709@gmail.com>
	<alpine.DEB.2.11.1501061120440.4080@whisky.home.derickrethans.nl>
	<CAEZPtU69a2MwH5aqigAUEp8+KcjR+w9pd81EvzvM1_z4ES34rQ@mail.gmail.com>
	<001b01d029bb$fa687fc0$ef397f40$@tekwire.net>
	<alpine.DEB.2.11.1501070959000.4080@whisky.home.derickrethans.nl>
	<CAEZPtU67htboPTt6PefLaEREbkobnPY=BpjKpRGg3B1o8xC0Vg@mail.gmail.com>
	<00a201d02ac7$406a4830$c13ed890$@tekwire.net>
Date: Thu, 8 Jan 2015 12:41:10 +0100
Message-ID: <CAEPJdu=ASPf97sWP8RNQzMvCOB3gx2e0SRctGG9wYzkOW2YYew@mail.gmail.com>
To: francois@tekwire.net
Cc: Pierre Joye <pierre.php@gmail.com>, Derick Rethans <derick@php.net>, 
	PHP internals <internals@lists.php.net>, Sara Golemon <pollita@php.net>, 
	Stanislav Malyshev <smalyshev@gmail.com>
Content-Type: multipart/alternative; boundary=f46d04426a603959b5050c22845a
Subject: Re: [PHP-DEV] [RFC] Extension Prepend Files
From: kontakt@beberlei.de (Benjamin Eberlei)

--f46d04426a603959b5050c22845a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 7, 2015 at 11:14 PM, Fran=C3=A7ois Laupretre <francois@tekwire.=
net>
wrote:

> > De : Pierre Joye [mailto:pierre.php@gmail.com]
> >
> > ... here,
> > it is proposed to bundle scripts that will be executed at runtime like
> any
> > other script, except that nothing can be done with them, not even disab=
le
> > them if not required (like using its own glue codes).
>
> I agree. Bundling scripts in extensions to execute them at each RINIT is,
> IMO, not a good idea (mostly for performance reasons and lack of control,
> as you note), but I keep thinking that a mechanism to embed PHP scripts i=
n
> extensions and make them available via a common stream wrapper can be
> useful. What I don't like is the fact to execute them automatically at
> every RINIT. I prefer to let the extension free to load its PHP code when
> its logic decides it is needed.
>

To be honest, I don't see the use case of shipping optional PHP code inside
an extension. As the user of an extension I want all the functions/classes
to be available all the time, no matter if the extension developer wrote
everything in C or in PHP.

For optional code there is Composer/PEAR/php include path, this is already
a solved problem.


> > Pickle integration is almost finished, that solves your worries about
> composer and pecl extensions.
>
> Both mechanisms can coexist. They are not incompatible and probably
> fulfill different needs.
>
> You are asking for a standard path for plain files linked to an extension=
.
> As putting the shared library and plain files together is not a good idea=
,
> what about something like this :
>
> <php-install-prefix>/lib/php/extensions/php/<extension-name>
>
> A C macro can be defined to provide the path to the extension C code, in
> order to avoid hardcoding it (this way, it could be modified in the futur=
e).
>
> At install time, we could say that every files under
> <extension-source-dir>/php/install, if this dir exists, are installed the=
re.
>
> It is just an example but does it correspond to the mechanism you were
> thinking about ?
>
> What is not clear to me is the question of
> packaging/versioning/deployment. If you consider the PHP glue code is
> modified more often than the C code, which will be the most frequent case=
,
> how do you version/distribute partial packages ? or do you deliver 2
> packages with independent versioning and dependencies together ? In this
> case, should we define a versioning convention for both packages ?
>
> Regards
>
> Fran=C3=A7ois
>
>
>

--f46d04426a603959b5050c22845a--