Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:6332
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <6.0.1.1.0.20031210164214.01ae17d8@pop.laposte.net>
Date: Wed, 10 Dec 2003 16:55:13 +0100
To: "Paternoster Sergio" <Sergio.Paternoster@h3g.it>,
	"Wez Furlong" <wez@thebrainroom.com>, <internals@lists.php.net>,
	<pecl-dev@lists.php.net>
In-Reply-To: <6D8EC0BD4950244E862A03E86DB9C0D90B231F@MIEXC03.h3g.it>
References: <6D8EC0BD4950244E862A03E86DB9C0D90B231F@MIEXC03.h3g.it>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: RE: [PECL-DEV] FUD-Buster: What is PECL, and how does moving
  stuff to PECL help us with the core?
From: e.colinet@laposte.net (Eric COLINET)

Hi,

>I'd like to write a new PHP extension, I know C, even if I'm not a guru, 
>but I didn't find a good tutorial about Zend API. Seems that the one on 
>Zend's website is an old version. Am I wrong?

Yes the documentation is a little old but it helps.

A book on this subject has been released (Building Custom PHP Extensions by 
Blake Schwendiman - I don't know if it's good stuff).

But the best way I know is to look at the existings extension either in 
PECL or in the ext directory of the PHP sources.

Regards,
Eric


At 10:06 10/12/2003, Paternoster Sergio wrote:
>Hi all,
>I'd like to write a new PHP extension, I know C, even if I'm not a guru, 
>but I didn't find a good tutorial about Zend API. Seems that the one on 
>Zend's website is an old version. Am I wrong?
>Thanx in advance
>regards
>Sergio
>
>-----Original Message-----
>From: Wez Furlong [mailto:wez@thebrainroom.com]
>Sent: Tuesday, 09 December, 2003 18:41
>To: internals@lists.php.net; pecl-dev@lists.php.net
>Subject: [PECL-DEV] FUD-Buster: What is PECL, and how does moving stuff
>to PECL help us with the core?
>
>
>It seems that most people still don't really get the idea behind
>PECL, and how moving extensions there is a good idea.
>
>Let me spell it out for you:
>
>- PECL provides a way to keep your extensions self contained and
>   allows you to keep your own release cycle.
>- In addition, the packaging systems allows you to mark the package
>   with explicit, versioned, dependencies.
>- It is very easy to our users to install and upgrade these
>   "pickled" extensions.
>
>---> PECL is a great solution for self-contained extensions
>
>How does it help with the core?
>
>- As we move extensions from php-src/ext to pecl/, they can take
>   advantage of the PECL infrastructure.
>
>   This allows people to build their own PHP and pick and choose the
>   particular version(s) of extensions that they want to use.
>   They might not want to use the very latest stable version if they
>   have a policy for avoiding bugs; conversely, they might want to
>   be using the latest version of the extension because it fixes
>   some bugs.
>
>What is the resistance to moving stuff from the core?
>
>- PECL is still seen as Siberia.  Some developers "fear" that
>   putting extensions in PECL will result in them having lower
>   quality because PECL extensions are somehow harder to test.
>   This is a totally bogus argument.  Getting extensions from
>   PECL is just as hard or easy as getting anything else from CVS,
>   it is just an additional module to check out.  There is nothing
>   hard about that, unless you are lazy.
>
>   The new win32 build system doesn't give a damn about whether
>   your extension is in PECL or in the core; it will still compile
>   it and run any tests in the test suite; the unix build should
>   be able to do this too (currently it is a little painful for
>   regular, non-golden extensions, but that shouldn't be hard to fix).
>
>- Some developers simply cannot see that there are two "problems"
>   with having our "golden" extensions in PECL:
>
>   - Development
>   - Packaging
>
>   They see them as a combined issue, and get confused about how
>   to handle things.
>
>   Using appropriate means on the CVS server, we can make the golden
>   pecl extensions appear under ext/ at the time you check out the
>   sources.  Those sources will be HEAD, or whatever other branch
>   you requested.  Development continues as it always has done in
>   the past.
>
>   At Packaging time, when the Release Master (lets call him
>   Peter Piper) rolls the tarball, he will pick the latest stable
>   versions of those golden pecl extensions.
>   Typically, these will be the same versions as can be found on
>   the current branch, as golden extensions are kept in sync with
>   the core; but he may decide to use an older stable version of
>   the package if he decides the latest version isn't up to scratch.
>   The "pear bundle" tool makes it simple for Peter Piper to
>   "pick a pecl".
>
>   This approach gives us more flexibility with our releases, without
>   overly complicating the common case.
>
>   Furthermore, it allows the end user to build their extensions
>   as shared modules and then upgrade them to a more recent version
>   in between major releases of the core.
>
>I'm tired of hearing FUD about PECL; lets stop resisting it and
>start embracing it.
>
>--Wez.
>"King" of PECL
>(whatever that means)
>
>--
>PECL development discussion Mailing List (http://pecl.php.net/)
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>--
>PECL development discussion Mailing List (http://pecl.php.net/)
>To unsubscribe, visit: http://www.php.net/unsub.php