[PECL-DEV] FUD-Buster: What is PECL, and how does moving stuff to PECL help us with the core?

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/)

--
PECL development discussion Mailing List (http://pecl.php.net/)