[PHP-DEV] CVS Account Request: telecart

[danny gur]

helping in translation the php menual to hebrew.

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Changes to ext_skel for C++

[J Smith]

How about adding something like this to skeleton.c:

/* __begin_extern_c__ */
/* __end_extern_c__ */

And having the sed script in ext_skel replace them with the proper extern 
"C" stuff? That way there's no need for skeleton.cpp and just a few changes 
need to be made in skeleton.c.

J


Sascha Schumann wrote:

> On Fri, 29 Nov 2002, J Smith wrote:
> 
>>
>> Attached is a patch to ext_skel that adds an optional argument (--cpp)
>> that will create a PHP extension in C++ rather than C. Also attached is
>> skeleton.cpp, which basically mirrors ext/skeleton/skeleton.c with a few
>> modifications for using C++. I could've just made some changes to
>> skeleton.c and done some sed work in the ext_skel script, but I think
>> it's clearer to have them separated into two files.
> 
> I'm reluctant to duplicate the contents of the .c file for
> maintenance reason.  Cannot you just put the C++ specific
> code into a
> 
> /* Remove this part, if this is not a C++ extension */
> #ifdef __cplusplus
> 
> #endif
> 
> section?
> 
> - Sascha


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Changes to ext_skel for C++

[J Smith]

Is this a problem with VS.net or something? I've never done that with any of 
my C++ extensions and they've all worked fine on VC++ 6.

If it is a problem, though, I'll make the changes.

J

Shane Caraveo wrote:

> J Smith wrote:
>> Attached is a patch to ext_skel that adds an optional argument (--cpp)
>> that will create a PHP extension in C++ rather than C. Also attached is
>> skeleton.cpp, which basically mirrors ext/skeleton/skeleton.c with a few
>> modifications for using C++. I could've just made some changes to
>> skeleton.c and done some sed work in the ext_skel script, but I think
>> it's clearer to have them separated into two files.
>> 
>> The ext_skel patch is based on the current HEAD.
>> 
>> Comments?
>> 
>> J
> 
> skeleton.h also needs to be dealt with.  If you do not, visual studio
> will export symbols as c++ symbols and the extension will not work.
> Simple solution is to have
> 
> #ifdef __cplusplus
> extern "C" {
> #endif
> 
> at the top of skeleton.h, and close it at the bottom.
> 
> Shane


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Changes to ext_skel for C++

[Sascha Schumann]

On Fri, 29 Nov 2002, J Smith wrote:

>
> Attached is a patch to ext_skel that adds an optional argument (--cpp) that
> will create a PHP extension in C++ rather than C. Also attached is
> skeleton.cpp, which basically mirrors ext/skeleton/skeleton.c with a few
> modifications for using C++. I could've just made some changes to
> skeleton.c and done some sed work in the ext_skel script, but I think it's
> clearer to have them separated into two files.

I'm reluctant to duplicate the contents of the .c file for
maintenance reason.  Cannot you just put the C++ specific
code into a

/* Remove this part, if this is not a C++ extension */
#ifdef __cplusplus

#endif

section?

- Sascha

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Changes to ext_skel for C++

[Shane Caraveo]

J Smith wrote:

Attached is a patch to ext_skel that adds an optional argument (--cpp) that 
will create a PHP extension in C++ rather than C. Also attached is 
skeleton.cpp, which basically mirrors ext/skeleton/skeleton.c with a few 
modifications for using C++. I could've just made some changes to 
skeleton.c and done some sed work in the ext_skel script, but I think it's 
clearer to have them separated into two files. 

The ext_skel patch is based on the current HEAD.

Comments?

J

skeleton.h also needs to be dealt with.  If you do not, visual studio 
will export symbols as c++ symbols and the extension will not work. 
Simple solution is to have

#ifdef __cplusplus
extern "C" {
#endif

at the top of skeleton.h, and close it at the bottom.

Shane




--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [PATCH] +3 for Win32 CoInitalize/CoUninitialize Call Move, Please Apply

[Michael Sisolak]

We got +3 on applying this but missed it for 4.3.0 RC2.  Will someone
with the correct karma please apply it to the 4.3.0 tree?

Michael

--- Michael Sisolak <[EMAIL PROTECTED]> wrote:
> Date: Mon, 25 Nov 2002 10:32:13 -0800 (PST)
> From: Michael Sisolak <[EMAIL PROTECTED]>
> Subject: [PATCH 4.3.0] Win32 CoInitalize/CoUninitialize Call Move
> To: [EMAIL PROTECTED]
> 
> While stess testing the recent threading fixes under the ISAPI module
> I
> was seeing a lot of instability in IIS after the testing finished. 
> While the PHP pages would continue to load, no ASP pages would
> anymore.
>  I have tracked this down to the placement of the Win32
> CoInitialize()
> and CoUninitialize() calls.  In the current 4.3.0 release candidate
> CoInitialize() and CoUninitialize() are only called once per thread
> (from the basic_globals_ctor/_dtor in basic_functions.c).  According
> to
> Microsoft, however, at
>
http://msdn.microsoft.com/library/en-us/iisref/html/psdk/asp/devs0hm5.asp:
> 
> "COM initialization, from CoInitialize or CoInitializeEx, affects the
> thread in which it's called. For this reason, you cannot initialize
> COM
> unless you uninitialize it before returning from your callback
> function. [ . . .] CoInitialize and CoUninitialize need to be called
> in
> order. If one is called twice in a row, by different ISAPIs on the
> same
> thread, your users may see error 270."
> 
> This is exactly the error I am seeing: if I load an ASP page in a
> thread that has processed PHP pages I get the 270 error (reported as
> "Error -2147417842 (0x8001010e)").  I moved the CoInitilize call to
> PHP_RINIT_FUNCTION(basic) and CoUninitialize to
> PHP_RSHUTDOWN_FUNCTION(basic) and reran my stress testing.  After
> 100,000 PHP page loads IIS now remains stable and able to process
> both
> ASP and PHP pages.
> 
> I ran this by Zeev and he suggested that some kind of just-in-time
> COM
> initialization, but I'm not going to have the time to get to this
> full
> solution until later.  In the meantime for 4.3.0 I request that the
> attached patch is applied that moves the CoInitialize or
> CoInitializeEx
> calls to be per-request.  This is the last little fix that all the
> multi-threading bug fixing to make the ISAPI rock solid in 4.3.0
> requires.  I've done a lot of testing and feel very confident about
> including this patch.
> 
> Michael Sisolak
> [EMAIL PROTECTED]




__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--- basic_functions.c.orig  Fri Nov 08 10:49:32 2002
+++ basic_functions.c   Mon Nov 25 13:25:09 2002
@@ -959,10 +959,6 @@
memset(&BG(url_adapt_state), 0, sizeof(BG(url_adapt_state)));
memset(&BG(url_adapt_state_ex), 0, sizeof(BG(url_adapt_state_ex)));
 
-#ifdef PHP_WIN32
-   CoInitialize(NULL);
-#endif
-
BG(incomplete_class) = php_create_incomplete_class(TSRMLS_C);
 }
 
@@ -973,9 +969,6 @@
if (BG(sm_allowed_env_vars)) {
free(BG(sm_allowed_env_vars));
}
-#ifdef PHP_WIN32
-   CoUninitialize();
-#endif
 }
 
 
@@ -1102,6 +1095,10 @@
 
 PHP_RINIT_FUNCTION(basic)
 {
+#ifdef PHP_WIN32
+   CoInitialize(NULL);
+#endif
+
memset(BG(strtok_table), 0, 256);
BG(strtok_string) = NULL;
BG(strtok_zval) = NULL;
@@ -1182,6 +1179,10 @@
if (BG(mmap_file)) {
munmap(BG(mmap_file), BG(mmap_len));
}
+#endif
+
+#ifdef PHP_WIN32
+   CoUninitialize();
 #endif
 
return SUCCESS;


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] ZE2 + public/protected/private/final

[Marcus Börger]

At 17:40 29.11.2002, Andi Gutmans wrote:

At 06:25 PM 11/28/2002 +0100, Marcus Börger wrote:

With current ZE2 it is possible to instanciate an abstract class. That is 
a class
that has at least one abstract method. When we add a flag field to 
class_entry
struct we can handle this. We simply need to set an abstract flag for the 
class
entry when any abstract method is added or inherited.

I updated the full patch to do it that way:
http://marcus-boerger.de/php/ext/ze2/ze2-f3p-21128.diff.txt

I thought about this but am not quite sure how I feel about this. I know 
that theoretically in C++ and Java you can't instantiate such classes but 
I'm not sure it'd be too bad in PHP.
If I were to implement this I'd probably use a counter to *remember* how 
many abstract methods a class has.

Andi

I would like a list of abstract methods in case the error is at hand more.
On the other side i do not know if the check is what we want. I mean it 
keeps you away
from using abstract classes what is a must in C++/Java. But for PHP this is 
only valid
as long as we do not:
a) allow to dynamically add new methods to instances/classes
 (This would make some more thinks complicated but makes PHP more object 
oriented)
b) explicitly allow using abstract classes by decision here

Also the check has one negative aspect: it cost time (even thogh only a few 
small tests).

Your counter would be slower and could instead be simply computed when the 
error is
being generated. See pseudo code:
cnt = 0
foreach function in function_table
  if function->common.fn_flags & FN_ABSTRACT
cnt++

Since there is until now no need to change the class_entry while inheriting 
a method we
can also show the class in which the method was introduced. Maybe like 
shown below:

class test {
abstract funcition a();
}
class fail extends test {
}

$t = new fail();
Fatal Error: You cannot instanciate abstract class fail (abstract methods: 
test::a)

marcus

p.s. I updated the complete patch: 
http://marcus-boerger.de/php/ext/ze2/ze2-f3p-21129.diff
after your commit.


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: #20673 [Opn->Ver]: Inexplicable arithmetical error due to references

[Michael Mauch]

[EMAIL PROTECTED] wrote in php.bugs:

> [2002-11-27 07:04:52] [EMAIL PROTECTED]
> 
>  $a = 7;
> $a = $a + $a++;
> echo $a; 
> //the result is 14;
> ?>
> 
> When I add a reference to $a, the behavior of $a + $a++ becomes
> inexplicable different. Note that $a isn't changed anywhere!
> 
>  $a = 7;
> $b =& $a;
> $a = $a + $a++;
> echo $a; 
> //the result is 15;
> ?>
> 
> The only difference is $b =& $a, but why $a takes care of references to
> itself?

Ilia verified the bug, and I can reproduce that behaviour here as well.
But I'm not sure whether the expressions

  $a = $a + $a++;

or

  $x = $a + $a++;

really are valid/legal/well-defined expressions. When exactly is that
$a++ meant to be interpreted/executed? Before or after that other $a is
looked at?

I know that PHP is not C, but hasn't that something to do with sections
3.1 to 3.3 of the C FAQ, ?

Regards...
Michael

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [PATCH] Changes to ext_skel for C++

[J Smith]

Attached is a patch to ext_skel that adds an optional argument (--cpp) that 
will create a PHP extension in C++ rather than C. Also attached is 
skeleton.cpp, which basically mirrors ext/skeleton/skeleton.c with a few 
modifications for using C++. I could've just made some changes to 
skeleton.c and done some sed work in the ext_skel script, but I think it's 
clearer to have them separated into two files. 

The ext_skel patch is based on the current HEAD.

Comments?

J
Index: ext_skel
===
RCS file: /repository/php4/ext/ext_skel,v
retrieving revision 1.44
diff -u -3 -p -r1.44 ext_skel
--- ext_skel	18 Nov 2002 15:55:07 -	1.44
+++ ext_skel	29 Nov 2002 18:20:40 -
@@ -7,7 +7,7 @@ givup() {
 
 usage() {
 echo "$0 --extname=module [--proto=file] [--stubs=file] [--xml[=file]]"
-echo "   [--skel=dir] [--full-xml] [--no-help]"
+echo "   [--skel=dir] [--full-xml] [--no-help] [--cpp]"
 echo ""
 echo "  --extname=module   module is the name of your extension"
 echo "  --proto=file   file contains prototypes of functions to create"
@@ -18,6 +18,7 @@ echo "  --full-xml generate xml 
 echo " (not yet implemented)"
 echo "  --no-help  don't try to be nice and create comments in the code"
 echo " and helper functions to test if the module compiled"
+echo "  --cpp  create a C++ extension"
 exit 1
 }
 
@@ -58,6 +59,9 @@ while test $# -gt 0; do
 --skel=?*)
 	skel_dir=$optarg
 	;;
+--cpp)
+cpp="yes"
+;;
 *)
 	usage
 	;;
@@ -94,7 +98,7 @@ if test -z "$stubs"; then
 fi
 
 if test -n "$proto"; then
-  cat $proto | awk -v extname=$extname -v stubs=$stubs -v stubfile=$stubfile -v xml=$xml -v full_xml=$full_xml -v i_know_what_to_do_shut_up_i_dont_need_your_help_mode=$no_help -f $skel_dir/create_stubs
+  cat $proto | awk -v extname=$extname -v stubs=$stubs -v stubfile=$stubfile -v xml=$xml -v full_xml=$full_xml -v i_know_what_to_do_shut_up_i_dont_need_your_help_mode=$no_help -v cpp=$cpp -f $skel_dir/create_stubs
 fi
 
 if test -z "$stubs"; then
@@ -165,11 +169,16 @@ if test "\$PHP_$EXTNAME" != "no"; then
   dnl ])
   dnl
   dnl PHP_SUBST(${EXTNAME}_SHARED_LIBADD)
+eof
 
-  PHP_NEW_EXTENSION($extname, $extname.c, \$ext_shared)
+if test "$cpp" = "yes"; then
+  echo "  PHP_REQUIRE_CXX()" >>config.m4
+  echo "  PHP_NEW_EXTENSION($extname, $extname.cpp, \$ext_shared)" >>config.m4
+else
+  echo "  PHP_NEW_EXTENSION($extname, $extname.c, \$ext_shared)" >>config.m4
 fi
-eof
 
+echo "fi" >>config.m4
 
 $ECHO_N " .cvsignore$ECHO_C"
 cat >.cvsignore <.cvsignore < sedscript
 echo "s/EXTNAME/$EXTNAME/g"  >> sedscript
 echo '/__function_entries_here__/r function_entries'  >> sedscript
@@ -189,6 +202,7 @@ echo '/__function_entries_here__/D'  >> 
 echo '/__function_stubs_here__/D'  >> sedscript
 echo '/__header_here__/D'  >> sedscript
 echo '/__footer_here__/D'  >> sedscript
+
 if [ ! -z "$no_help" ]; then
 echo "/confirm_$extname_compiled/D" >> sedscript
 echo '/Remove the following/,/^\*\//D' >> sedscript
@@ -197,7 +211,11 @@ if [ ! -z "$no_help" ]; then
 echo '/^[[:space:]]*\/\*/,/^[[:space:]]*\*\//D' >> sedscript
 fi
 
-sed -f sedscript < $skel_dir/skeleton.c > $extname.c
+if test "$cpp" = "yes"; then
+sed -f sedscript < $skel_dir/skeleton.cpp > $extname.cpp
+else
+sed -f sedscript < $skel_dir/skeleton.c > $extname.c
+fi
 
 
 $ECHO_N " php_$extname.h$ECHO_C"
@@ -273,7 +291,15 @@ To use your new extension, you will have
 4.  $ ./configure --[with|enable]-$extname
 5.  $ make
 6.  $ ./php -f ext/$extname/$extname.php
-7.  $ vi ext/$extname/$extname.c
+eof
+
+  if test "$cpp" = "yes"; then
+  echo "7.  $ vi ext/$extname/$extname.cpp"
+  else
+  echo "7.  $ vi ext/$extname/$extname.c"
+  fi
+
+  cat <
/* __header_here__ */

#ifdef HAVE_CONFIG_H
#include "config.h"
#endif

extern "C" {
#include "php.h"
#include "php_ini.h"
#include "ext/standard/info.h"
}

#include "php_extname.h"

// C++ header...

#include 

using namespace std;

/* If you declare any globals in php_extname.h uncomment this:
ZEND_DECLARE_MODULE_GLOBALS(extname)
*/

/* True global resources - no need for thread safety here */
static int le_extname;

/* {{{ extname_functions[]
 *
 * Every user visible function must have an entry in extname_functions[].
 */
function_entry extname_functions[] = {
	PHP_FE(confirm_extname_compiled,	NULL)		/* For testing, remove later. */
	/* __function_entries_here__ */
	{NULL, NULL, NULL}	/* Must be the last line in extname_functions[] */
};
/* }}} */

/* {{{ extname_module_entry
 */
zend_module_entry extname_module_entry = {
#if ZEND_MODULE_API_NO >= 20010901
	STANDARD_MODULE_HEADER,
#endif
	"extname",
	extname_functions,
	PHP_MINIT(extname),
	PHP_MSHUTDOWN(extname),
	PHP_RINIT(extname),		/* Replace with NULL if there's nothing to do at request start */
	PHP_RSHUTDOWN(extname),	/* Replace with NULL if there's nothing to do at request end */
	PHP_MI

Re: [PHP-DEV] Bug #20308 (Feature Request)

[Sara Golemon]

>> I'm not so much worried about the user in this case, a few explodes
>> will keep them happy.  I'm more worried about the behavior of
>> parse_url being just plain lacking.
>> mailto:[EMAIL PROTECTED]?subject=Bug+20308 should be entitled to
>> everybit as much parsing as
>> http://joe:[EMAIL PROTECTED]/pathto/somepage?var=value
>>
>> The ONLY real concern here, and reason for not fixing php_url_parse,
>> comes in the fact that 'path' would no longer contain
>> '[EMAIL PROTECTED]?subject=Bug+20308' (per the example above) which
>> would likely break existing scripts.
>>
>> Perhaps the compromise is to create a new function 'parse_url_rfc'
>> (name could be better) which behaves correctly (without having special
>> cases). Then add a note to the manpage for parse_url saying to use
>> parse_url_rfc instead, and eventually deprecate parse_url (perhaps
>> with PHP 5.0).
>
> No. parse_url_rfc would be misleading because it would not follow RFC.
> There  are special rules for scheme:, scheme:/ and scheme://, your
> suggested patch  would actually break RFC, since mailto: is already
> parsed properly according  to RFC.
> E-mail addresses are not urls, if we want to offer an email parser it
> should  be separate function parse_email or something similar, there is
> no need to  pollute php_parse_url() with hacks for non-intended
> functionality.

Okay, okay... I throw my hands up...





-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Modules/Extensions not in 4.3

[Wez Furlong]

Hi Philip,

On Fri, 29 Nov 2002, Philip Olson wrote:

> So "mainstream" is defined as which are bundled with the
> PHP4 source, whether it's in PECL or not?  Does anyone
> know or have a list of what will go where and when? Is
> the install, configure, and use process different for
> PECL extensions?  Why are any PECL extensions bundled in
> PHP4 source?  That seems to defeat the purpose.

As I just explained to you on IRC (and repeating here "for the record"),
the aim is to have a virtually empty php5/ext/ directory and have all
extensions (besides standard) living in PECL.
Once in PECL, the extensions gain dependency tracking information.

When we publish a release, we will pick the "gold" extensions based on
the userbase (popular extensions will be included by default) and the
level of maintenance (crufty extensions might not be bundled by
default).

> > So, what I'd like to see (and this seems reasonable, IMO) is:
> >
> > o One doc download for the PHP core + bundled extensions (which may
> > reside in PECL).
> > o One doc download for the PEAR classes + non-bundled PECL extensions
> > o One doc download for extension developers (the streams and zend API
> > stuff needs a proper home).
> > o One doc system to rule them all (but keep it modular of course).
>
> Regarding the separate developers manual, the main reason it
> hasn't already been done (aside from time constraints) is there
> is question on whether it should be translated or not.  I vote no
> it shouldn't as that'd mean outdated developer docs as the zendapi
> stuff seems to change a lot and translations are slow and
> sometimes are just one-time operations.  In fact, aren't the current
> en zendapi docs already outdated?  I don't know this topic.  On a
> related note, those PHP4/README.* docs would  fit nicely in this
> dev manual.

Yes, the developer docs should be written only in english for the
reasons you mention above (which are similar to the reasons for not
localizing the php error messages).

--Wez.


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Bug #20308 (Feature Request)

[Ilia A.]

On November 29, 2002 12:41 pm, Sara Golemon wrote:
> >> It looks like php_url_parse can be modified to return user and host
> >> for mailto schemes without making it a 'special case', but that would
> >> also remove the current 'path' index which would break existing PHP
> >> code ((bad)).
> >>
> >> So we can (A) put in a special case, or (B) not modify the function at
> >> all.  Either way leaves someone unhappy so in the absence of a
> >> majority I can't help but do nothing.  This request will have to
> >> remain open, at least for now.
> >
> > Users requests all kinds of features all the time, just because someone
> > will  be unhappy because their request is not implemented is hardly a
> > reason to  implement it. As a rule, special cases are bad, if you REALLY
> > think this is  useful functionality we are better off adding a
> > parse_email() function, who's  job would be to break email addresses
> > into parts.
>
> I'm not so much worried about the user in this case, a few explodes will
> keep them happy.  I'm more worried about the behavior of parse_url being
> just plain lacking.   mailto:[EMAIL PROTECTED]?subject=Bug+20308 should be
> entitled to everybit as much parsing as
> http://joe:[EMAIL PROTECTED]/pathto/somepage?var=value
>
> The ONLY real concern here, and reason for not fixing php_url_parse, comes
> in the fact that 'path' would no longer contain
> '[EMAIL PROTECTED]?subject=Bug+20308' (per the example above) which would
> likely break existing scripts.
>
> Perhaps the compromise is to create a new function 'parse_url_rfc' (name
> could be better) which behaves correctly (without having special cases).
> Then add a note to the manpage for parse_url saying to use parse_url_rfc
> instead, and eventually deprecate parse_url (perhaps with PHP 5.0).

No. parse_url_rfc would be misleading because it would not follow RFC. There 
are special rules for scheme:, scheme:/ and scheme://, your suggested patch 
would actually break RFC, since mailto: is already parsed properly according 
to RFC. 
E-mail addresses are not urls, if we want to offer an email parser it should 
be separate function parse_email or something similar, there is no need to 
pollute php_parse_url() with hacks for non-intended functionality.

Ilia

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Bug #20308 (Feature Request)

[Wez Furlong]

On Fri, 29 Nov 2002, Sara Golemon wrote:

> I'm not so much worried about the user in this case, a few explodes will
> keep them happy.  I'm more worried about the behavior of parse_url being
> just plain lacking.   mailto:[EMAIL PROTECTED]?subject=Bug+20308 should be
> entitled to everybit as much parsing as
> http://joe:[EMAIL PROTECTED]/pathto/somepage?var=value
>
> The ONLY real concern here, and reason for not fixing php_url_parse, comes
> in the fact that 'path' would no longer contain
> '[EMAIL PROTECTED]?subject=Bug+20308' (per the example above) which would
> likely break existing scripts.

Because mailto URL is not one of the common internet/host URLs (that
parse_url was designed to handle), this should not happen.

> Perhaps the compromise is to create a new function 'parse_url_rfc' (name
> could be better) which behaves correctly (without having special cases).
> Then add a note to the manpage for parse_url saying to use parse_url_rfc
> instead, and eventually depricate parse_url (perhaps with PHP 5.0).

But which RFC would it follow? There are at least 3 :)

Why not just use the Net_URL pear package?

--Wez.


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Modules/Extensions not in 4.3

[Philip Olson]

> On Fri, 29 Nov 2002, Wez Furlong wrote:
> IMO, the manual should include all of the "maintstream" PHP extensions.
> The reasoning is that if someone downloads the PHP manual, they expect
> to get the PHP manual and not have to hunt around for docs on extensions
> X, Y, Z.

So "mainstream" is defined as which are bundled with the
PHP4 source, whether it's in PECL or not?  Does anyone
know or have a list of what will go where and when? Is
the install, configure, and use process different for
PECL extensions?  Why are any PECL extensions bundled in
PHP4 source?  That seems to defeat the purpose.

Currently the php and pear docs are like separate entities,
perhaps we should tie them closer together.  Like,
download-docs.php can include versions with the pear manual.
And php.net/{pearextension} can either redirect to or
load appropriate manual/info pages.  Anyway, point is
they can be better and closer friends.

> Remember that one of our goals is to move most of ext/* into PECL, but
> still bundle these pickled extensions in our official release packages,
> so the idea that PECL should be documented under PEAR is not such a good
> one.

I'm not familiar with this topic.  Currently PECL is documented
under PEAR, and since it's part of PEAR it makes sense.  It's
hard enough to decide which extensions go into PECL let alone
which PECL are documented in what manual.  I am curious what is
meant by "most", that sounds a little scary and makes having
all extensions in one manual more attractive.  Is there an
option to only download needed pecl at compile time, kinda
like how 'pear install foo' is done now?  Or an option to
download each separate, or all of them at once?  I don't see
why any PECL would be bundled.  But anyway, back to the docs.

Some disadvantages of having the docs separate:

 * phpdoc has a ton more translators.
 * more people have phpdoc karma and feel comfortable
   touching phpdoc source
 * downloading two manuals and/or viewing two websites
 * "most" living in pecl, yet many bundled in php4

With the main advantage being it would be in its proper home.

> Again, IMO, the madness of having no less than 3 different docu systems
> (phpdoc, peardoc and peardoc2) makes very little sense; why not just use
> "one system (tm)" for docs? (let's save some developer brain power for
> more useful things).

The peardoc/peardoc2 issue is temporary and confusing but will
be remedied at some point, not sure when.  In fact, I personally
don't document pear because of it.  The matter of a completely 
separate PECL manual I also disagree with.  Although who knows,
maybe if the build processes were more closely done together it 
wouldn't be so bad.

> So, what I'd like to see (and this seems reasonable, IMO) is:
> 
> o One doc download for the PHP core + bundled extensions (which may
> reside in PECL).
> o One doc download for the PEAR classes + non-bundled PECL extensions
> o One doc download for extension developers (the streams and zend API
> stuff needs a proper home).
> o One doc system to rule them all (but keep it modular of course).

I agree with this except have reservations about some PECL
going in PEAR manual while others in the main manual.  I
*strongly* agree with a uniform system but AFAICT it won't
exactly be the case with current plans (phpdocumentor).

Regarding the separate developers manual, the main reason it
hasn't already been done (aside from time constraints) is there 
is question on whether it should be translated or not.  I vote no 
it shouldn't as that'd mean outdated developer docs as the zendapi 
stuff seems to change a lot and translations are slow and
sometimes are just one-time operations.  In fact, aren't the current 
en zendapi docs already outdated?  I don't know this topic.  On a 
related note, those PHP4/README.* docs would  fit nicely in this 
dev manual.

Regards,
Philip


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Bug #20308 (Feature Request)

[Sara Golemon]

>> It looks like php_url_parse can be modified to return user and host
>> for mailto schemes without making it a 'special case', but that would
>> also remove the current 'path' index which would break existing PHP
>> code ((bad)).
>>
>> So we can (A) put in a special case, or (B) not modify the function at
>> all.  Either way leaves someone unhappy so in the absence of a
>> majority I can't help but do nothing.  This request will have to
>> remain open, at least for now.
>
> Users requests all kinds of features all the time, just because someone
> will  be unhappy because their request is not implemented is hardly a
> reason to  implement it. As a rule, special cases are bad, if you REALLY
> think this is  useful functionality we are better off adding a
> parse_email() function, who's  job would be to break email addresses
> into parts.
>
I'm not so much worried about the user in this case, a few explodes will
keep them happy.  I'm more worried about the behavior of parse_url being
just plain lacking.   mailto:[EMAIL PROTECTED]?subject=Bug+20308 should be
entitled to everybit as much parsing as
http://joe:[EMAIL PROTECTED]/pathto/somepage?var=value

The ONLY real concern here, and reason for not fixing php_url_parse, comes
in the fact that 'path' would no longer contain
'[EMAIL PROTECTED]?subject=Bug+20308' (per the example above) which would
likely break existing scripts.

Perhaps the compromise is to create a new function 'parse_url_rfc' (name
could be better) which behaves correctly (without having special cases). 
Then add a note to the manpage for parse_url saying to use parse_url_rfc
instead, and eventually depricate parse_url (perhaps with PHP 5.0).

-Pollita



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] ZE2 + public/protected/private/final

[Andi Gutmans]

At 06:25 PM 11/28/2002 +0100, Marcus Börger wrote:

With current ZE2 it is possible to instanciate an abstract class. That is 
a class
that has at least one abstract method. When we add a flag field to class_entry
struct we can handle this. We simply need to set an abstract flag for the 
class
entry when any abstract method is added or inherited.

I updated the full patch to do it that way:
http://marcus-boerger.de/php/ext/ze2/ze2-f3p-21128.diff.txt

I thought about this but am not quite sure how I feel about this. I know 
that theoretically in C++ and Java you can't instantiate such classes but 
I'm not sure it'd be too bad in PHP.
If I were to implement this I'd probably use a counter to *remember* how 
many abstract methods a class has.

Andi


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] ZE2 question

[Andi Gutmans]

At 04:30 PM 11/28/2002 +, James Cox wrote:

it means double colon in hebrew... i think Zeev and Andi must not have known
what to call it in english when they put it in... but hey, it was the first
i18n'ized error message :)


We are very attached to this token because it was put in when we were 
coding very late one night a few years ago :)

Andi


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] ZE2 and standard class initialization

[Andi Gutmans]

Applied.

Andi

At 05:31 PM 11/28/2002 +0100, Marcus Börger wrote:

In ZE2  zend.c there is a structure member not initialized for. See patch 
below.

marcus
Index: Zend/zend.c
===
RCS file: /repository/ZendEngine2/zend.c,v
retrieving revision 1.191
diff -u -r1.191 zend.c
--- Zend/zend.c 24 Nov 2002 20:15:56 -  1.191
+++ Zend/zend.c 28 Nov 2002 16:24:02 -
@@ -289,6 +289,8 @@
zend_standard_class_def->handle_property_get = NULL;
zend_standard_class_def->handle_property_set = NULL;
zend_standard_class_def->refcount = 1;
+   zend_standard_class_def->constants_updated = 0;
zend_hash_add(GLOBAL_CLASS_TABLE, "stdclass", sizeof("stdclass"), 
&zend_standard_class_def, sizeof(zend_class_entry *), NULL);
 }



--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] C++ extensions and ext_skel

[J Smith]

The only modified file is ext_skel. There's also the addition of a file in 
ext/skeleton -- skeleton.cpp to go along with skeleton.c. I suppose I could 
get rid of the .cpp file, make a few changes to skeleton.c and have 
ext_skel make the proper modifications when it's replacing "extname", 
"EXTNAME" and whatnot. The changes to config.m4 and Makefile.in are done in 
ext_skel.

J


Sascha Schumann wrote:

> On Thu, 28 Nov 2002, J Smith wrote:
> 
>>
>> A couple of times a month, I get questions about from people looking to
>> use C++ with PHP. Apparently, a lot of people end up reading some post I
>> made to php.dev or something a year or so ago about C++, and although it
>> worked at the time, the procedure I describe has become stale.
>>
>> I messed around a bit with ext_skel and ext/skeleton today and added an
>> option to ext_skel (--cpp) that creates a basic C++ extension rather than
>> the standard C extension. The C++ extension is pretty much the same as
>> the standard C extension, with the exception of some extern "C" linkage,
>> modifications to config.m4 and Makefile.in and a small C++ class thrown
>> in for fun.
> 
> Cannot those be unified?
> 
> - Sascha

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] test

[J Smith]

test, please ignore

J

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] RE: [PEAR-DOC] Re: [PHP-DEV] Re: Modules/Extensions not in 4.3

[LIMBOURG Arnaud]

Well, you suggestion makes sense. I wonder about something though. How
different are phpdoc/peardoc/peardoc2 ?

As i said the plan was to move from peardoc to peardoc2. If we move
everything to phpdoc we'll have to port peardoc and peardoc2 to phpdoc, it
will need a lot of work.

There is also a project to generate peardoc2 automoatically from PHPDoc
comments using phpdocumentor and others scripts, greg beaver as well as
alexander are working on that. If peardoc2 and phpdoc are compatible that
would be great.

Arnaud.


> IMO, the manual should include all of the "maintstream" PHP 
> extensions.
> The reasoning is that if someone downloads the PHP manual, they expect
> to get the PHP manual and not have to hunt around for docs on 
> extensions
> X, Y, Z.
> 
> Remember that one of our goals is to move most of ext/* into PECL, but
> still bundle these pickled extensions in our official release 
> packages,
> so the idea that PECL should be documented under PEAR is not 
> such a good
> one.
> 
> Again, IMO, the madness of having no less than 3 different 
> docu systems
> (phpdoc, peardoc and peardoc2) makes very little sense; why 
> not just use
> "one system (tm)" for docs? (let's save some developer brain power for
> more useful things).
> 
> So, what I'd like to see (and this seems reasonable, IMO) is:
> 
> o One doc download for the PHP core + bundled extensions (which may
> reside in PECL).
> o One doc download for the PEAR classes + non-bundled PECL extensions
> o One doc download for extension developers (the streams and zend API
> stuff needs a proper home).
> o One doc system to rule them all (but keep it modular of course).
> 
> --Wez.
> 
> On Fri, 29 Nov 2002, Philip Olson wrote:
> 
> > > >> The peardoc format will be phased out for peardoc2 which
> > > >> uses several files, that is one per function, one for 
> constants,
> > > >> etc.
> > > >>
> > > >> It makes sense to document PECL in the pear manual 
> since PECL is
> > > >> in pear.
> > > >
> > > > Well, actually this what I wanted to hear :) I also 
> think that moving
> > > > PECL module's manuals to PECL is the way to go. Those 
> extensions are
> > > > mostly rarely used... We can make up a list in the 
> manual about moved
> > > > extensions and some text about why this happened / happens...
> > >
> > > IMO, a lot of extensions that are currently documented in the PHP
> > > manual could be moved to PECL and PEAR doc. This would make the
> > > PHP manual lighter to download, display, handle. The PHP manual
> > > could keep documentation about the core extensions (still to be
> > > defined).
> >
> > This isn't really the question as we (the doc teams) don't make
> > these (php4/ext->pecl) decisions.  I don't think anyone feels
> > the documentation of PECL modules belong in the php manual or
> > vice versa but the question is how and when to deal with the
> > moved extensions.  When the php-dev team moves an extension we:
> >
> >   (a) Move the docs (phpdoc->peardoc)
> >
> >   Verify the docs are online in the pear manual before removed
> >   from the php manual. (which means the peardoc vs peardoc2
> >   craziness must also be dealt with)
> >
> >   (b) Make sure php.net/{extensionname} still does something
> >   useful.
> >
> >   Whether filler pages or 404 handles this is in question.
> >   And whether or not individual functions are kept track
> >   of is another.  Also, this may just refer to (c).
> >
> >   (c) Make a note in an up-and-coming phpdoc appendix page on
> >   moved and removed extensions which may look like:
> >
> >   =
> >   | Extension | Change | Reason   | Moved in  |
> >   =
> >aspell   removed  pspell..   4.3.0
> >cybercashremoved  ...4.3.0
> >cybermut moved..  ...4.3.0
> >   -
> >
> >   (d) ???
> >
> > Ideally the php-dev team can provide a timeline for (some) future
> > moves and/or discuss each extension in detail and make a decision.
> > Maybe all moves have been completed?.  For now, we rely on NEWS
> > entries.
> >
> > Most of the above applies to removed extensions too except they
> > won't go into peardoc but rather remain in phpdoc for an
> > undisclosed (a long) amount of time.  A few were removed in 4.3.0,
> > see NEWS and CVS entries for details.  Removed/deprecated
> > extensions have been dealt with in a couple different ways:
> >
> >   (1) icap   : php.net/icap simply redirects to php.net/mcal
> >icap docs are not generated.
> >   (2) aspell : All deprecated functions have been listed for
> >quite some time.  It also mentions "use pspell"
> >   (3) Redirect to (c) above.
> >
> > I prefer the second because of historical reasons and the
> > fact that users may still be using the old functions.  For
> > how long will these docs remain?  Should th

[PHP-DEV] Some image functions are broken

[Marcus Börger]

i was just about to create some image (ext/gd) tests while i found
out that imagegd2 and imagefromgd functions are broken. I checked
with versions 4.3 and cvs.

- You can convert an image to gd but you cannot reload it.
- You cannot create an gd2 image.
- png -> jpeg and reverse is good.

[marcus@zaphod php4-HEAD]$ make sapi/cli/php ; php -r 
'imagegd(imagecreatefrompng($argv[1]), $argv[2]);' -- ext/gd/tests/test.png 
ext/gd/tests/test.gd
make: `sapi/cli/php' is up to date.
[marcus@zaphod php4-HEAD]$ make sapi/cli/php ; php -r 
'imagegd2(imagecreatefrompng($argv[1]), $argv[2]);' -- 
ext/gd/tests/test.png ext/gd/tests/test.gd2
make: `sapi/cli/php' is up to date.
Segmentation fault
[marcus@zaphod php4-HEAD]$ make sapi/cli/php ; php -r 
'imagepng(imagecreatefromgd($argv[1]), $argv[2]);' -- ext/gd/tests/test.gd 
ext/gd/tests/test1.png
make: `sapi/cli/php' is up to date.
Segmentation fault
[marcus@zaphod php4-HEAD]$ make sapi/cli/php ; php -r 
'imagejpeg(imagecreatefrompng($argv[1]), $argv[2]);' -- 
ext/gd/tests/test.png ext/gd/tests/test.jpeg
make: `sapi/cli/php' is up to date.
[marcus@zaphod php4-HEAD]$ make sapi/cli/php ; php -r 
'imagepng(imagecreatefromjpeg($argv[1]), $argv[2]);' -- 
ext/gd/tests/test.jpeg ext/gd/tests/test.1.png
make: `sapi/cli/php' is up to date.
[marcus@zaphod php4-HEAD]$ cm
cmp cmuwmtopbm
[marcus@zaphod php4-HEAD]$ cmp ext/gd/tests/test.png ext/gd/tests/test.1.png
ext/gd/tests/test.png ext/gd/tests/test.1.png differ: char 36, line 3

They differ because jpeg compression losses. :-) But the result looks o.k.

marcus


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Bug #20308 (Feature Request)

[Ilia A.]

On November 29, 2002 01:05 am, Sara Golemon wrote:
> >> I disagree with this, the current behaviour is imho wrong.
> >>
> >> mailto: is a url, rejecting the patch because it introduces a special
> >> case, is not a good thing.  parse_url() is for _all_ url's, not just
> >> http:// url's, and besides, the current syntax for mailto is
> >> completely valid, and should be parsed anyway.
> >>
> >> (ie, a special case shouldn't be required if the url parser was rfc
> >> compliant).
> >
> > PHP's php_url_parse() function is not in any way limited to http:// as
> > you  claim, it support a large variety of valid URLs, take a look at the
> > very  extensive test for parse_url() function located here:
> > ext/standard/tests/strings/url_t.phpt.
> > Even the regular expression described in RFC 2396 does not recognize
> > mailto: any differently the our very own parse_url().
>
> It looks like php_url_parse can be modified to return user and host for
> mailto schemes without making it a 'special case', but that would also
> remove the current 'path' index which would break existing PHP code
> ((bad)).
>
> So we can (A) put in a special case, or (B) not modify the function at
> all.  Either way leaves someone unhappy so in the absence of a majority I
> can't help but do nothing.  This request will have to remain open, at
> least for now.

Users requests all kinds of features all the time, just because someone will 
be unhappy because their request is not implemented is hardly a reason to 
implement it. As a rule, special cases are bad, if you REALLY think this is 
useful functionality we are better off adding a parse_email() function, who's 
job would be to break email addresses into parts.

Ilia

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Modules/Extensions not in 4.3

[Sebastian Nohn]

Wez Furlong schrieb:

> o One doc download for the PHP core + bundled extensions
> (which may
> reside in PECL).
> o One doc download for the PEAR classes + non-bundled
> PECL extensions
> o One doc download for extension developers (the streams
> and zend API
> stuff needs a proper home).
> o One doc system to rule them all (but keep it modular of
> course).

+1

Regards, Sebastian Nohn
-- 
[EMAIL PROTECTED] - http://nohn.net/

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Modules/Extensions not in 4.3

[Wez Furlong]

IMO, the manual should include all of the "maintstream" PHP extensions.
The reasoning is that if someone downloads the PHP manual, they expect
to get the PHP manual and not have to hunt around for docs on extensions
X, Y, Z.

Remember that one of our goals is to move most of ext/* into PECL, but
still bundle these pickled extensions in our official release packages,
so the idea that PECL should be documented under PEAR is not such a good
one.

Again, IMO, the madness of having no less than 3 different docu systems
(phpdoc, peardoc and peardoc2) makes very little sense; why not just use
"one system (tm)" for docs? (let's save some developer brain power for
more useful things).

So, what I'd like to see (and this seems reasonable, IMO) is:

o One doc download for the PHP core + bundled extensions (which may
reside in PECL).
o One doc download for the PEAR classes + non-bundled PECL extensions
o One doc download for extension developers (the streams and zend API
stuff needs a proper home).
o One doc system to rule them all (but keep it modular of course).

--Wez.

On Fri, 29 Nov 2002, Philip Olson wrote:

> > >> The peardoc format will be phased out for peardoc2 which
> > >> uses several files, that is one per function, one for constants,
> > >> etc.
> > >>
> > >> It makes sense to document PECL in the pear manual since PECL is
> > >> in pear.
> > >
> > > Well, actually this what I wanted to hear :) I also think that moving
> > > PECL module's manuals to PECL is the way to go. Those extensions are
> > > mostly rarely used... We can make up a list in the manual about moved
> > > extensions and some text about why this happened / happens...
> >
> > IMO, a lot of extensions that are currently documented in the PHP
> > manual could be moved to PECL and PEAR doc. This would make the
> > PHP manual lighter to download, display, handle. The PHP manual
> > could keep documentation about the core extensions (still to be
> > defined).
>
> This isn't really the question as we (the doc teams) don't make
> these (php4/ext->pecl) decisions.  I don't think anyone feels
> the documentation of PECL modules belong in the php manual or
> vice versa but the question is how and when to deal with the
> moved extensions.  When the php-dev team moves an extension we:
>
>   (a) Move the docs (phpdoc->peardoc)
>
>   Verify the docs are online in the pear manual before removed
>   from the php manual. (which means the peardoc vs peardoc2
>   craziness must also be dealt with)
>
>   (b) Make sure php.net/{extensionname} still does something
>   useful.
>
>   Whether filler pages or 404 handles this is in question.
>   And whether or not individual functions are kept track
>   of is another.  Also, this may just refer to (c).
>
>   (c) Make a note in an up-and-coming phpdoc appendix page on
>   moved and removed extensions which may look like:
>
>   =
>   | Extension | Change | Reason   | Moved in  |
>   =
>aspell   removed  pspell..   4.3.0
>cybercashremoved  ...4.3.0
>cybermut moved..  ...4.3.0
>   -
>
>   (d) ???
>
> Ideally the php-dev team can provide a timeline for (some) future
> moves and/or discuss each extension in detail and make a decision.
> Maybe all moves have been completed?.  For now, we rely on NEWS
> entries.
>
> Most of the above applies to removed extensions too except they
> won't go into peardoc but rather remain in phpdoc for an
> undisclosed (a long) amount of time.  A few were removed in 4.3.0,
> see NEWS and CVS entries for details.  Removed/deprecated
> extensions have been dealt with in a couple different ways:
>
>   (1) icap   : php.net/icap simply redirects to php.net/mcal
>icap docs are not generated.
>   (2) aspell : All deprecated functions have been listed for
>quite some time.  It also mentions "use pspell"
>   (3) Redirect to (c) above.
>
> I prefer the second because of historical reasons and the
> fact that users may still be using the old functions.  For
> how long will these docs remain?  Should they ever go in the
> appendix instead?  Will this confuse users?  These are good
> questions :)  Also, what is done may depend on the individual
> extensions themselves although consistancy has its merits.
>
> Regards,
> Philip Olson
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Modules/Extensions not in 4.3

[Marcus Börger]

ext/db is deprecated by dba since 4.3 (earlier versions of dba are very 
different).
I plan on emulating db calls in ext/dba. If this is done we can either 
remove db
or move it to pecl (i vote for removing then). The remaining difference 
current
difference between the two is that db uses magic quotes for key names while
dba does not. I plan to make the wrapper functions in dba work exactly the 
same
way as in db.

If you want to do something about those two extensions now you could simply
add a note to every db page that db is deprecated and also add a link to the
corresponding dba functions.

regards
marcus

At 11:57 29.11.2002, Philip Olson wrote:
> >> The peardoc format will be phased out for peardoc2 which
> >> uses several files, that is one per function, one for constants,
> >> etc.
> >>
> >> It makes sense to document PECL in the pear manual since PECL is
> >> in pear.
> >
> > Well, actually this what I wanted to hear :) I also think that moving
> > PECL module's manuals to PECL is the way to go. Those extensions are
> > mostly rarely used... We can make up a list in the manual about moved
> > extensions and some text about why this happened / happens...
>
> IMO, a lot of extensions that are currently documented in the PHP
> manual could be moved to PECL and PEAR doc. This would make the
> PHP manual lighter to download, display, handle. The PHP manual
> could keep documentation about the core extensions (still to be
> defined).

This isn't really the question as we (the doc teams) don't make
these (php4/ext->pecl) decisions.  I don't think anyone feels
the documentation of PECL modules belong in the php manual or
vice versa but the question is how and when to deal with the
moved extensions.  When the php-dev team moves an extension we:

  (a) Move the docs (phpdoc->peardoc)

  Verify the docs are online in the pear manual before removed
  from the php manual. (which means the peardoc vs peardoc2
  craziness must also be dealt with)

  (b) Make sure php.net/{extensionname} still does something
  useful.

  Whether filler pages or 404 handles this is in question.
  And whether or not individual functions are kept track
  of is another.  Also, this may just refer to (c).

  (c) Make a note in an up-and-coming phpdoc appendix page on
  moved and removed extensions which may look like:

  =
  | Extension | Change | Reason   | Moved in  |
  =
   aspell   removed  pspell..   4.3.0
   cybercashremoved  ...4.3.0
   cybermut moved..  ...4.3.0
  -

  (d) ???

Ideally the php-dev team can provide a timeline for (some) future
moves and/or discuss each extension in detail and make a decision.
Maybe all moves have been completed?.  For now, we rely on NEWS
entries.

Most of the above applies to removed extensions too except they
won't go into peardoc but rather remain in phpdoc for an
undisclosed (a long) amount of time.  A few were removed in 4.3.0,
see NEWS and CVS entries for details.  Removed/deprecated
extensions have been dealt with in a couple different ways:

  (1) icap   : php.net/icap simply redirects to php.net/mcal
   icap docs are not generated.
  (2) aspell : All deprecated functions have been listed for
   quite some time.  It also mentions "use pspell"
  (3) Redirect to (c) above.

I prefer the second because of historical reasons and the
fact that users may still be using the old functions.  For
how long will these docs remain?  Should they ever go in the
appendix instead?  Will this confuse users?  These are good
questions :)  Also, what is done may depend on the individual
extensions themselves although consistancy has its merits.

Regards,
Philip Olson


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php



--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Modules/Extensions not in 4.3

[Philip Olson]

> >> The peardoc format will be phased out for peardoc2 which
> >> uses several files, that is one per function, one for constants, 
> >> etc.
> >>
> >> It makes sense to document PECL in the pear manual since PECL is 
> >> in pear.
> >
> > Well, actually this what I wanted to hear :) I also think that moving
> > PECL module's manuals to PECL is the way to go. Those extensions are
> > mostly rarely used... We can make up a list in the manual about moved
> > extensions and some text about why this happened / happens...
>
> IMO, a lot of extensions that are currently documented in the PHP 
> manual could be moved to PECL and PEAR doc. This would make the 
> PHP manual lighter to download, display, handle. The PHP manual 
> could keep documentation about the core extensions (still to be
> defined).

This isn't really the question as we (the doc teams) don't make
these (php4/ext->pecl) decisions.  I don't think anyone feels 
the documentation of PECL modules belong in the php manual or 
vice versa but the question is how and when to deal with the 
moved extensions.  When the php-dev team moves an extension we:

  (a) Move the docs (phpdoc->peardoc)

  Verify the docs are online in the pear manual before removed
  from the php manual. (which means the peardoc vs peardoc2
  craziness must also be dealt with)

  (b) Make sure php.net/{extensionname} still does something
  useful.

  Whether filler pages or 404 handles this is in question.
  And whether or not individual functions are kept track
  of is another.  Also, this may just refer to (c).

  (c) Make a note in an up-and-coming phpdoc appendix page on
  moved and removed extensions which may look like:

  =
  | Extension | Change | Reason   | Moved in  |
  =
   aspell   removed  pspell..   4.3.0
   cybercashremoved  ...4.3.0
   cybermut moved..  ...4.3.0
  -

  (d) ???

Ideally the php-dev team can provide a timeline for (some) future
moves and/or discuss each extension in detail and make a decision.  
Maybe all moves have been completed?.  For now, we rely on NEWS 
entries.

Most of the above applies to removed extensions too except they
won't go into peardoc but rather remain in phpdoc for an
undisclosed (a long) amount of time.  A few were removed in 4.3.0, 
see NEWS and CVS entries for details.  Removed/deprecated 
extensions have been dealt with in a couple different ways:

  (1) icap   : php.net/icap simply redirects to php.net/mcal
   icap docs are not generated.
  (2) aspell : All deprecated functions have been listed for
   quite some time.  It also mentions "use pspell"
  (3) Redirect to (c) above.

I prefer the second because of historical reasons and the 
fact that users may still be using the old functions.  For
how long will these docs remain?  Should they ever go in the 
appendix instead?  Will this confuse users?  These are good 
questions :)  Also, what is done may depend on the individual 
extensions themselves although consistancy has its merits.

Regards,
Philip Olson


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Default Return-Path with mail() and qmail

[Daniel Lorch]

hi,

>> I'm a big -1 on this.  The patch will not actually solve the root problem.
>>
>> On Unix systems, the MTA needs to know that the webserver user is
>> 'trusted' to masquerade as another user.  In exim this would be the
>> 'trusted-users' directive, sendmail, qmail, and postfix have similar
>> directives.

Thanks for pointing this out. I was pretty sure there was something un-RFC-ish
about my patch. However, I think the patch creates a more intuitive behaviour:
If the user supplies a "From: " header, he expects all replies coming back to
this address -- be it human generated responses or bounce messages.

In contrast to qmail-inject (handling local mails), qmail-smtp (the SMTP-daemon)
DOES use the "From" header (of the mail envelope, not header) for the
Return-Path. I would call this inconsistent behaviour. However, I'm currently
discussing this on the qmail mailing list, please don't be bothered by this
here :)

> You might consider recommending a configuration setting like the following 
> in each  block on a multi-domain Apache server.  This sends 
> bounces and replies to the webmaster of the domain if no attempt is made to 
> set the From: and Reply-to: headers when mail() is used.
> 
> 
> pph_admin_value sendmail_path "/usr/sbin/sendmail -t [EMAIL PROTECTED]"

That's actually a good proposition. The documentation team might want to
catch this up. Unfortunately, this doesn't work with my setup, as I'm
(mod_cgi-)wrapping all scripts. 

-daniel

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] IRCG/PHP and Apache 1.3

[Sascha Schumann]

Hi!

For all of you who are interested in running IRCG in
combination with Apache 1.3, have a look at:

http://schumann.cx/ircg/ircg4.php>

--
About IRCG

IRCG is a revolutionary way for dispatching messages to huge
groups of users over an arbitrary number of separate
communication channels in real-time. IRCG provides message
streams over persistent HTTP connections and can interface
with a subsystem to produce static file snippets. All aspects
of IRCG are scriptable using PHP. IRCG is format and content
agnostic, and can produce any output format you require,
including XML, XHTML/HTML, and WML.

Typical applications of IRCG include online gaming/gambling
sites and web chat systems.

- Sascha

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php