Documenting the Zend2 extension API

19 years ago by Gwynne Raskind — view source — reply

unread

Given the recent discussion of the lack of real documentation for the
Zend API, and the endless links provided to various sources of
usually incomplete information, I thought it might be a good idea if
someone wrote an actual book on the subject. I'm interested in taking
that project upon myself, and I'm wondering what advice anyone has to
offer on the idea.

-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."

19 years ago by Derick Rethans — view source — reply

unread

Given the recent discussion of the lack of real documentation for the Zend
API, and the endless links provided to various sources of usually incomplete
information, I thought it might be a good idea if someone wrote an actual book
on the subject. I'm interested in taking that project upon myself, and I'm
wondering what advice anyone has to offer on the idea.

There is one:
http://www.amazon.com/Extending-Embedding-PHP-Developers-Library/dp/067232704X/ref=sr_1_1/102-2890754-1426549?ie=UTF8&s=books&qid=1177529537&sr=8-1

regards,
Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

19 years ago by Gwynne Raskind — view source — reply

unread

Given the recent discussion of the lack of real documentation for
the Zend
API, and the endless links provided to various sources of usually
incomplete
information, I thought it might be a good idea if someone wrote an
actual book
on the subject. I'm interested in taking that project upon myself,
and I'm
wondering what advice anyone has to offer on the idea.
There is one:
http://www.amazon.com/Extending-Embedding-PHP-Developers-Library/dp/
067232704X/ref=sr_1_1/102-2890754-1426549?
ie=UTF8&s=books&qid=1177529537&sr=8-1

Hmm... For some reason I missed that in my searches. That being said,
the existence of one doesn't preclude the writing of another :).
Also, it seems the official documentation in the PHP manual could use
some serious updating, which I would also be willing to undertake if
people think that would be more useful.

-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."

19 years ago by Antony Dovgal — view source — reply

unread

Hmm... For some reason I missed that in my searches. That being said,
the existence of one doesn't preclude the writing of another :).
Also, it seems the official documentation in the PHP manual could use
some serious updating, which I would also be willing to undertake if
people think that would be more useful.

Actually I've been recently thinking of adding some kind of documentation to the sources.
Surely this is not supposed to be something similar to php.net/manual/, just short
descriptions of functions and their arguments, which can be used as a start for the "real"
documentation.
But I wasn't lucky enough to find a utility that would fit my (personal) needs.

Doxygen (which seems to be uses by the majority of F/OSS projects) generates completely unreadable docs.
Every time I look into ICU docs (generated by Doxygen) I get lost for 10 minutes trying to find a function by name.
In the same time, other tools do not provide such a wide range of output formats as available in Doxygen.

Anyways ZE internals documentation definitely needs serious update and this would be very much appreciated.
The only problem is that you need to know the internals a bit (or at least want to learn it) to be
able to document it, and all the people with this knowledge are busy with other things most of the time..
You can count on me if you need any help/hints, though.

--
Wbr,
Antony Dovgal

19 years ago by Marcus Boerger — view source — reply

unread

Hello Antony,

Thursday, April 26, 2007, 12:05:07 AM, you wrote:

Hmm... For some reason I missed that in my searches. That being said,
the existence of one doesn't preclude the writing of another :).
Also, it seems the official documentation in the PHP manual could use
some serious updating, which I would also be willing to undertake if
people think that would be more useful.

Actually I've been recently thinking of adding some kind of documentation to the sources.
Surely this is not supposed to be something similar to php.net/manual/, just short
descriptions of functions and their arguments, which can be used as a start for the "real"
documentation.
But I wasn't lucky enough to find a utility that would fit my (personal) needs.

Doxygen (which seems to be uses by the majority of F/OSS projects)
generates completely unreadable docs.
Every time I look into ICU docs (generated by Doxygen) I get lost for 10
minutes trying to find a function by name.
In the same time, other tools do not provide such a wide range of output formats as available in Doxygen.

Hu? It has a search option if you want. And it has alphabetical lists for
functions, consts, classes, files, modules, whatever. And if that is not
enough we could take it's xml output to feed a database and provide a
fulltext search on that.

Anyways ZE internals documentation definitely needs serious update and this would be very much appreciated.
The only problem is that you need to know the internals a bit (or at least want to learn it) to be
able to document it, and all the people with this knowledge are busy with other things most of the time..
You can count on me if you need any help/hints, though.

--
Wbr,
Antony Dovgal

Best regards,
Marcus

19 years ago by Antony Dovgal — view source — reply

unread

Doxygen (which seems to be uses by the majority of F/OSS projects)
generates completely unreadable docs.
Every time I look into ICU docs (generated by Doxygen) I get lost for 10
minutes trying to find a function by name.
In the same time, other tools do not provide such a wide range of output formats as available in Doxygen.

Hu? It has a search option if you want.

This one? =)
http://www.icu-project.org/apiref/icu4c/search.php?query=strcat

And it has alphabetical lists for
functions, consts, classes, files, modules, whatever.

Maybe there is something wrong with ICU docs (or with me?), but I can't find any alphabetical index of functions.
All I can see is a list of functions per file, which is noway convenient.

And if that is not enough we could take it's xml output to feed a database and provide a
fulltext search on that.

We can also use any of search engines available to search in the result HTML.
But the point is that the docs should be well structured enough so that a fulltext search would not be required.

--
Wbr,
Antony Dovgal

19 years ago by Marcus Boerger — view source — reply

unread

Hello Antony,

Thursday, April 26, 2007, 12:25:30 AM, you wrote:

Doxygen (which seems to be uses by the majority of F/OSS projects)
generates completely unreadable docs.
Every time I look into ICU docs (generated by Doxygen) I get lost for 10
minutes trying to find a function by name.
In the same time, other tools do not provide such a wide range of output formats as available in Doxygen.

Hu? It has a search option if you want.

This one? =)
http://www.icu-project.org/apiref/icu4c/search.php?query=strcat

And it has alphabetical lists for
functions, consts, classes, files, modules, whatever.

Maybe there is something wrong with ICU docs (or with me?), but I can't
find any alphabetical index of functions.
All I can see is a list of functions per file, which is noway convenient.

Go to: http://www.php.net/~helly/php/ext/spl/
On the left select 'file members'
Then on the top of the main part select 'functions'
That will give you all global functions.

Now, open 'Class Members' on the left
Then on the top of the main part select 'functions'
That will give you a list of all functions,
each with a list of classes/interfaces implementing them

And if that is not enough we could take it's xml output to feed a database and provide a
fulltext search on that.

We can also use any of search engines available to search in the result HTML.
But the point is that the docs should be well structured enough so that a
fulltext search would not be required.

As i said, from doxygen' XML output we can generate any kind of
structure we see fit.

best regards
marcus

19 years ago by Antony Dovgal — view source — reply

unread

Hello Antony,

Thursday, April 26, 2007, 12:25:30 AM, you wrote:

Doxygen (which seems to be uses by the majority of F/OSS projects)
generates completely unreadable docs.
Every time I look into ICU docs (generated by Doxygen) I get lost for 10
minutes trying to find a function by name.
In the same time, other tools do not provide such a wide range of output formats as available in Doxygen.

Hu? It has a search option if you want.

This one? =)
http://www.icu-project.org/apiref/icu4c/search.php?query=strcat

And it has alphabetical lists for
functions, consts, classes, files, modules, whatever.

Maybe there is something wrong with ICU docs (or with me?), but I can't
find any alphabetical index of functions.
All I can see is a list of functions per file, which is noway convenient.

Go to: http://www.php.net/~helly/php/ext/spl/
On the left select 'file members'
Then on the top of the main part select 'functions'
That will give you all global functions.

You really think this is good structure?

Now, open 'Class Members' on the left
Then on the top of the main part select 'functions'
That will give you a list of all functions,
each with a list of classes/interfaces implementing them

4 clicks just to get to the list of functions?
No, doxygen is definitely not what I would like to use.

And if that is not enough we could take it's xml output to feed a database and provide a
fulltext search on that.

We can also use any of search engines available to search in the result HTML.
But the point is that the docs should be well structured enough so that a
fulltext search would not be required.

As i said, from doxygen' XML output we can generate any kind of
structure we see fit.

--
Wbr,
Antony Dovgal

19 years ago by Derick Rethans — view source — reply

unread

Hello Antony,

Thursday, April 26, 2007, 12:05:07 AM, you wrote:

Hmm... For some reason I missed that in my searches. That being
said, the existence of one doesn't preclude the writing of another
:). Also, it seems the official documentation in the PHP manual
could use some serious updating, which I would also be willing to
undertake if people think that would be more useful.

Actually I've been recently thinking of adding some kind of
documentation to the sources. Surely this is not supposed to be
something similar to php.net/manual/, just short descriptions of
functions and their arguments, which can be used as a start for the
"real" documentation. But I wasn't lucky enough to find a utility
that would fit my (personal) needs.

Doxygen (which seems to be uses by the majority of F/OSS projects)
generates completely unreadable docs. Every time I look into ICU
docs (generated by Doxygen) I get lost for 10 minutes trying to find
a function by name. In the same time, other tools do not provide
such a wide range of output formats as available in Doxygen.

Hu? It has a search option if you want. And it has alphabetical lists
for functions, consts, classes, files, modules, whatever. And if that
is not enough we could take it's xml output to feed a database and
provide a fulltext search on that.

That doesn't make the docs more readable though...

Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

19 years ago by Gwynne Raskind — view source — reply

unread

Hmm... For some reason I missed that in my searches. That being
said, the existence of one doesn't preclude the writing of
another :). Also, it seems the official documentation in the PHP
manual could use some serious updating, which I would also be
willing to undertake if people think that would be more useful.
Actually I've been recently thinking of adding some kind of
documentation to the sources.
Surely this is not supposed to be something similar to php.net/
manual/, just short descriptions of functions and their arguments,
which can be used as a start for the "real" documentation.
But I wasn't lucky enough to find a utility that would fit my
(personal) needs.

Doxygen (which seems to be uses by the majority of F/OSS projects)
generates completely unreadable docs.
Every time I look into ICU docs (generated by Doxygen) I get lost
for 10 minutes trying to find a function by name.
In the same time, other tools do not provide such a wide range of
output formats as available in Doxygen.

Anyways ZE internals documentation definitely needs serious update
and this would be very much appreciated.
The only problem is that you need to know the internals a bit (or
at least want to learn it) to be able to document it, and all the
people with this knowledge are busy with other things most of the
time..
You can count on me if you need any help/hints, though.

I've been plugging around writing extensions long enough to have some
idea of the internals; more than once I've answered a question by
digging through the Zend sources for the internals of some API. I'm
willing to at least take a crack at this project; the worst I can do
is fail :). Would it make sense to ask for CVS karma on the docs now
or wait a bit?

-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."

19 years ago by Antony Dovgal — view source — reply

unread

I've been plugging around writing extensions long enough to have some
idea of the internals; more than once I've answered a question by
digging through the Zend sources for the internals of some API.

Great!

I'm willing to at least take a crack at this project; the worst I can do
is fail :). Would it make sense to ask for CVS karma on the docs now
or wait a bit?

I believe the best way to get karma is to start sending patches.

I would also recommend to establish the build environment for the docs (if you don't have one already),
it's good idea to test patches before committing.
This document should give you a good start: http://doc.php.net/php/dochowto/index.php

--
Wbr,
Antony Dovgal

19 years ago by Steph — view source — reply

unread

and that will teach me to read to the end of the thread before I respond.

What Tony said :)

----- Original Message -----
From: "Antony Dovgal" antony@zend.com
To: "Gwynne Raskind" gwynne@wanderingknights.org
Cc: internals@lists.php.net
Sent: Wednesday, April 25, 2007 11:51 PM
Subject: Re: [PHP-DEV] Documenting the Zend2 extension API

I've been plugging around writing extensions long enough to have some
idea of the internals; more than once I've answered a question by
digging through the Zend sources for the internals of some API.

Great!

I'm willing to at least take a crack at this project; the worst I can do
is fail :). Would it make sense to ask for CVS karma on the docs now or
wait a bit?

I believe the best way to get karma is to start sending patches.

I would also recommend to establish the build environment for the docs (if
you don't have one already), it's good idea to test patches before
committing.
This document should give you a good start:
http://doc.php.net/php/dochowto/index.php

--
Wbr, Antony Dovgal

19 years ago by Gwynne Raskind — view source — reply

unread

I've been plugging around writing extensions long enough to have
some idea of the internals; more than once I've answered a
question by digging through the Zend sources for the internals of
some API.
Great!
I'm willing to at least take a crack at this project; the worst I
can do is fail :). Would it make sense to ask for CVS karma on
the docs now or wait a bit?
I believe the best way to get karma is to start sending patches.

I would also recommend to establish the build environment for the
docs (if you don't have one already), it's good idea to test
patches before committing.
This document should give you a good start: http://doc.php.net/php/
dochowto/index.php

Hi all, just wanted to give you a heads-up that I'm still working on
this project; it took me awhile to get the tools properly set up, but
I'm plugging away at DocBook XML now, and I'll have a few patches to
send in soon, I think. Thanks for all the advice so far!

-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."

19 years ago by Philip Olson — view source — reply

unread

I've been plugging around writing extensions long enough to have
some idea of the internals; more than once I've answered a
question by digging through the Zend sources for the internals
of some API.
Great!
I'm willing to at least take a crack at this project; the worst
I can do is fail :). Would it make sense to ask for CVS karma on
the docs now or wait a bit?
I believe the best way to get karma is to start sending patches.

I would also recommend to establish the build environment for the
docs (if you don't have one already), it's good idea to test
patches before committing.
This document should give you a good start: http://doc.php.net/php/
dochowto/index.php

Hi all, just wanted to give you a heads-up that I'm still working
on this project; it took me awhile to get the tools properly set
up, but I'm plugging away at DocBook XML now, and I'll have a few
patches to send in soon, I think. Thanks for all the advice so far!

Hello Gwynne,

This is excellent news, and feel free to write the doc list if you
have any questions and/or the IRC channels on efnet (#php.pecl and
#php.doc). As far as information on the topic goes, let's start a
list of the current landscape (with ideas to steal from):

The official docs: http://php.net/manual/internals
CodeGen_PECL: http://pear.php.net/package/codegen_pecl
A few tutorials: http://devzone.zend.com/public/view/tag/extension
The book: Extending and Embedding PHP by Sara Golemon
Many README files in php-src: http://cvs.php.net/viewvc.cgi/php-src/
A few talks: http://talks.php.net/index.php/Internals
A nice talk: http://netevil.org/talks/furlong-golemon-extending-
php.pdf
More talks: http://talks.somabo.de/
A nice talk: http://talks.somabo.de/
200610_zend_conf_php_extension_development.pdf
A few examples: http://people.apache.org/~nabeel/php/examples/

Also, let's create a FAQ section dedicated to the topic of extension
writing.

Regards,
Philip

19 years ago by Gwynne Raskind — view source — reply

unread

Hi all, just wanted to give you a heads-up that I'm still working
on this project; it took me awhile to get the tools properly set
up, but I'm plugging away at DocBook XML now, and I'll have a few
patches to send in soon, I think. Thanks for all the advice so far!
Hello Gwynne,

This is excellent news, and feel free to write the doc list if you
have any questions and/or the IRC channels on efnet (#php.pecl and
#php.doc). As far as information on the topic goes, let's start a
list of the current landscape (with ideas to steal from):

The official docs: http://php.net/manual/internals

CodeGen_PECL: http://pear.php.net/package/codegen_pecl

A few tutorials: http://devzone.zend.com/public/view/tag/extension

The book: Extending and Embedding PHP by Sara Golemon

Many README files in php-src: http://cvs.php.net/viewvc.cgi/php-src/

A few talks: http://talks.php.net/index.php/Internals

A nice talk: http://netevil.org/talks/furlong-golemon-extending-
php.pdf

More talks: http://talks.somabo.de/

A nice talk: http://talks.somabo.de/
200610_zend_conf_php_extension_development.pdf

A few examples: http://people.apache.org/~nabeel/php/examples/

Also, let's create a FAQ section dedicated to the topic of
extension writing.

This list of links has been extremely helpful to me, Philip; I
appreciate it a lot :). I'm embarassed to say I came down with a bit
of writer's block lately, so I don't have any patches to send in yet,
unfortunately. However, I would like the opinion of the list on the
avenue I've chosen.

Basically, it's my estimation that the existing internals
documentation in the manual is not organized very well, nor lends
itself to updating with any manner of ease. The material I've been
writing is a new section dedicated to the API of ZE2, rather than
trying to consolidate all the information for ZE1 (outdated) and ZE3
(still changing almost every day). My preliminary outline for the
content looks like this (yanked out of my diffs for manual.xml.in and
subject to change):

<part id="internals2"> <title>&Internals2;</title> &internals2.intro; &internals2.buildsys.index;  &internals2.structure.index;  &internals2.memory.index;  &internals2.variables.index;  &internals2.functions.index;  &internals2.objects.index;  &internals2.resources.index;  &internals2.ini.index;  &internals2.streams.index;   &internals2.apiref.index;  &internals2.ze1.index;  &internals2.ze3.index;  </part>

My thinking is to document ZE2 completely, since the differences
between 1 and 2 are small enough for the existing internals section
to be of use to anyone writing for 1, and 3 can be more fully
documented later (something I'm willing to take on as well).

If I'm given a thumbs-down on this way of doing things, I'll take the
material I've written already and use it to update the existing
internals section, but I think this method has the best chance of
giving people the truly comprehensive online reference we've lacked
for extension writing up to this point.

-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."

19 years ago by Gwynne Raskind — view source — reply

unread

Hi all, just wanted to give you a heads-up that I'm still working
on this project; it took me awhile to get the tools properly set
up, but I'm plugging away at DocBook XML now, and I'll have a few
patches to send in soon, I think. Thanks for all the advice so far!
Hello Gwynne,

This is excellent news, and feel free to write the doc list if you
have any questions and/or the IRC channels on efnet (#php.pecl and
#php.doc). As far as information on the topic goes, let's start a
list of the current landscape (with ideas to steal from):

The official docs: http://php.net/manual/internals

CodeGen_PECL: http://pear.php.net/package/codegen_pecl

A few tutorials: http://devzone.zend.com/public/view/tag/extension

The book: Extending and Embedding PHP by Sara Golemon

Many README files in php-src: http://cvs.php.net/viewvc.cgi/php-src/

A few talks: http://talks.php.net/index.php/Internals

A nice talk: http://netevil.org/talks/furlong-golemon-extending-
php.pdf

More talks: http://talks.somabo.de/

A nice talk: http://talks.somabo.de/
200610_zend_conf_php_extension_development.pdf

A few examples: http://people.apache.org/~nabeel/php/examples/

Also, let's create a FAQ section dedicated to the topic of
extension writing.

-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."

19 years ago by Philip Olson — view source — reply

unread

<part id="internals2"> <title>&Internals2;</title> &internals2.intro; &internals2.buildsys.index;  &internals2.structure.index;  &internals2.memory.index;  &internals2.variables.index;  &internals2.functions.index;  &internals2.objects.index;  &internals2.resources.index;  &internals2.ini.index;  &internals2.streams.index;   &internals2.apiref.index;  &internals2.ze1.index;  &internals2.ze3.index;  </part>
My thinking is to document ZE2 completely, since the differences
between 1 and 2 are small enough for the existing internals section
to be of use to anyone writing for 1, and 3 can be more fully
documented later (something I'm willing to take on as well).

If I'm given a thumbs-down on this way of doing things, I'll take
the material I've written already and use it to update the existing
internals section, but I think this method has the best chance of
giving people the truly comprehensive online reference we've lacked
for extension writing up to this point.

Hello Gwynne,

Sounds good. Many times silence on this list means "Sounds good" and
internals isn't too keen on defining a structure for
documentation... :) So, go for it! Always feel free to ask questions
while documenting this and as it all progresses let's be sure
internals reviews the information too. Once the information is in
manageable and smaller pieces you'll likely have more success getting
feedback. And don't be a stranger on #php.pecl @ efnet (IRC) either.

Regards,
Philip

19 years ago by Andi Gutmans — view source — reply

unread

Btw, the book Derick, Stig and I wrote ("PHP 5 Power Programming") also
has a chapter re: writing extensions. While it covers only a subset and
has not been updated, I think it does a good job in explaining some of
the fundamentals.
Reason why I bring this up is because the book is under the open
publication license and I believe it might allow you to steal some
pieces for the PHP manual. I can get you the exact license if you need
(it's been a while so I don't remember exactly which clauses we chose
but I think it can be used).

Andi

-----Original Message-----
From: Philip Olson [mailto:philip@roshambo.org]
Sent: Friday, June 01, 2007 9:31 PM
To: Gwynne Raskind
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Documenting the Zend2 extension API

<part id="internals2"> <title>&Internals2;</title> &internals2.intro; &internals2.buildsys.index;  &internals2.structure.index;  &internals2.memory.index; 

&internals2.variables.index; 
&internals2.functions.index; 
&internals2.objects.index; 
&internals2.resources.index; 
&internals2.ini.index; 
&internals2.streams.index; 

&internals2.apiref.index; 
&internals2.ze1.index; 
&internals2.ze3.index; 
</part>

My thinking is to document ZE2 completely, since the differences
between 1 and 2 are small enough for the existing internals
section to
be of use to anyone writing for 1, and 3 can be more fully
documented
later (something I'm willing to take on as well).

If I'm given a thumbs-down on this way of doing things,
I'll take the
material I've written already and use it to update the existing
internals section, but I think this method has the best chance of
giving people the truly comprehensive online reference we've lacked
for extension writing up to this point.

Hello Gwynne,

Sounds good. Many times silence on this list means "Sounds
good" and internals isn't too keen on defining a structure
for documentation... :) So, go for it! Always feel free to
ask questions while documenting this and as it all progresses
let's be sure internals reviews the information too. Once the
information is in manageable and smaller pieces you'll likely
have more success getting feedback. And don't be a stranger
on #php.pecl @ efnet (IRC) either.

Regards,
Philip

--
To
unsubscribe, visit: http://www.php.net/unsub.php

19 years ago by Stanislav Malyshev — view source — reply

unread

Doxygen (which seems to be uses by the majority of F/OSS projects)
generates completely unreadable docs.
Every time I look into ICU docs (generated by Doxygen) I get lost for 10
minutes trying to find a function by name.

Well, in ICU there are two sets of docs - the automatic docs (e.g.
http://www.icu-project.org/apiref/icu4c/unum_8h.html) and the human docs
(e.g. http://icu-project.org/userguide/formatNumbers.html). Ideally, we
should have both - the former is for checking the API, the latter is for
actually understanding what it does. There's no way to get the latter
doc except for actual person to write it. :)

The only problem is that you need to know the internals a bit (or at
least want to learn it) to be able to document it, and all the people
with this knowledge are busy with other things most of the time..
You can count on me if you need any help/hints, though.

Same here.

Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/

19 years ago by Wez Furlong — view source — reply

unread

We use doxygen for the developer portions of our customer facing
manual. The trick is to have it output xml and then massage that to
fit into docbook.

--Wez.

Doxygen (which seems to be uses by the majority of F/OSS projects) generates completely unreadable docs.
Every time I look into ICU docs (generated by Doxygen) I get lost for 10 minutes trying to find a function by name.
In the same time, other tools do not provide such a wide range of output formats as available in Doxygen.

Anyways ZE internals documentation definitely needs serious update and this would be very much appreciated.
The only problem is that you need to know the internals a bit (or at least want to learn it) to be
able to document it, and all the people with this knowledge are busy with other things most of the time..
You can count on me if you need any help/hints, though.

19 years ago by Steph — view source — reply

unread

Gwynne, I'm not wanting to be nasty or anything, but:

a) Sara is totally expert in this area and you, as yet, are not

b) the reason that was ever needed at all is that the open source stuff
needs work.

If you really want to make things easier for incomers, work on the open
source documentation on php.net. Please. It needs serious attention.

If you just want glorification, forget it - one with far stronger
credentials has gone before.

Steph

----- Original Message -----
From: "Gwynne Raskind" gwynne@wanderingknights.org
To: internals@lists.php.net
Sent: Wednesday, April 25, 2007 10:45 PM
Subject: Re: [PHP-DEV] Documenting the Zend2 extension API

Given the recent discussion of the lack of real documentation for the
Zend
API, and the endless links provided to various sources of usually
incomplete
information, I thought it might be a good idea if someone wrote an
actual book
on the subject. I'm interested in taking that project upon myself, and
I'm
wondering what advice anyone has to offer on the idea.
There is one:
http://www.amazon.com/Extending-Embedding-PHP-Developers-Library/dp/
067232704X/ref=sr_1_1/102-2890754-1426549?
ie=UTF8&s=books&qid=1177529537&sr=8-1

Hmm... For some reason I missed that in my searches. That being said, the
existence of one doesn't preclude the writing of another :). Also, it
seems the official documentation in the PHP manual could use some serious
updating, which I would also be willing to undertake if people think that
would be more useful.

-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."

Documenting the Zend2 extension API View as Markdown

Same here.