RE: [PHP-DEV] config.w32.h...registry configuration
Seriously, being able to include other ini files is a great feature, especially for hosters who will then be able to set up site-wide config files that are included from per-vhost config files, etc. You can have your cake and eat it too. Sure :). A way to make this functionnality on others server than apache is a must. The php_xxx directive let admin makes a custom config per host. On IIS, iplanet, there is actually no way to do it. Just do not forget these servers :). pa -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Extension news: cryptopp
Hello, I read some of the documentation, and noticed that this API seems to be very usable for an abstraction to multiple encryption libraries. It even looks a lot like the API I had in mind for the revamped mcrypt extension. Would you be interested in figuring the best way to do it, so that we have a nice crypto API for PHP 5? regards, Derick On Thu, 2 May 2002, J Smith wrote: Just thought I'd give an update about the current status of the Crypto++ extension for PHP I've been working on the past month or two, called simply cryptopp. The extension is coming along rather nicely and is stablizing towards a solid release. I'd still consider the current releases of beta quality and not to be trusted with 100% confidence, although I have not had a problem yet. (As more users try out the extension, I'll get a better idea of how well it's working, but I need feedback, which sadly has been slow-coming.) The good stuff: - Works on a bunch of platforms, including both UNIX platforms (Solaris 8 and linux tested; others should work if gcc/g++ work) and Windows platforms (Windows 2000 with VC++ 6 tested). Hopefully this will be of use to Windows PHP users, as I don't believe the win32 port of the libmcrypt libraries are being maintained anymore. - The extension implements 32 cryptographic ciphers (27 block ciphers, 5 stream ciphers), 14 cryptographic hashes and two checksum hashes. (CRC32 is included for completeness, even though there is already a CRC32 function in PHP.) - There is some compatibility with the mcrypt and mhash extensions. I haven't tested everything, but there are at least a few algorithms common to each that can produce compatible ciphertext. - There's a set of C bindings to the extension that you can use in other extensions. I guess. I had originally used the C bindings in the extension itself until I wised up. I left them there for others to use if they really want to. (The extension is written in C++, so the C bindings were originally to make using the C++ classes from PHP's C code easier.) The bad: - produces a big-ass executable when statically linked with PHP. My current Apache executable went from 3.3 MB or so to 5.3 MB after enabling the extension. VC++ 6 produces a DLL of 430 KB or so. This is 'cause unlike mcrypt and mhash there's no dynamic loading of ciphers or hashes. (Yet -- I may work on this later.) - there's no way to pick and choose which ciphers or hashes you'd like to compile in with the extension -- it's all or nothing. I'm also planning on working on this later. The latest version of the extension is 0.0.5. There were a few changes from the original version, 0.0.1, which are listed in the docs. To play around with the extension, head to http://www.tutorbuddy.com/software/. (Mirrored at http://209.202.82.229/software/.) J -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php --- Did I help you? http://www.amazon.co.uk/exec/obidos/registry/SLCB276UZU8B Frequent ranting: http://www.jdimedia.nl/derick/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Parsing an external URL
I'm in the process of rewriting a site in PHP (as I learn it) to make it more robust. One of the functions I regularly use is calling an external URL, parsing out the data I need and saving that data for use on my site. (Don't worry, we've made arrangements with these companies!) I'm unsure which function, include(), readfile() or any other to use where I can go through the called page and parse out what I need. Example, let's say I needed to get the page's title, I would need to be able to go through the file and find an tag object, discover the tag is a TITLE tag, start gathering the text object until I reach a tag object of /TITLE. If there are any tutorials on the subject, can someone point me in the right direction? Thanks! Mark [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/session session.c
Sebastian Bergmann wrote: sebastian Fri May 3 04:10:49 2002 EDT Modified files: /php4/ext/session session.c Log: Fix ZTS build. This fixes the ZTS build not completely, I get some errors in the .re file(s) as well, but I don't dare touching there, so ... :-) -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Parsing an external URL
This is not the list you should be asking this kind of questions on. This list is about developing PHP itself, not about developing WITH PHP. By the way, you don't want to use readfile() here. implode(, file()) seems like the easiest solution, in combination with preg_match, probably, for the problem you are describing. Regards, Manuzhai Miva Guy [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I'm in the process of rewriting a site in PHP (as I learn it) to make it more robust. One of the functions I regularly use is calling an external URL, parsing out the data I need and saving that data for use on my site. (Don't worry, we've made arrangements with these companies!) I'm unsure which function, include(), readfile() or any other to use where I can go through the called page and parse out what I need. Example, let's say I needed to get the page's title, I would need to be able to go through the file and find an tag object, discover the tag is a TITLE tag, start gathering the text object until I reach a tag object of /TITLE. If there are any tutorials on the subject, can someone point me in the right direction? Thanks! Mark [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/session session.c
On Fri, May 03, 2002 at 10:21:44AM +0200, Sebastian Bergmann wrote: Sebastian Bergmann wrote: sebastian Fri May 3 04:10:49 2002 EDT Modified files: /php4/ext/session session.c Log: Fix ZTS build. This fixes the ZTS build not completely, I get some errors in the .re file(s) as well, but I don't dare touching there, so ... :-) checking... -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: streams problem with mac line endings
Hi Derick, I'm not 100% sure if this should be fixed in streams itself; I'm mostly in agreement, but I don't want to cause some unexpected side effects when people use the user-space fgets() or the php_stream_gets() functions. I'm not saying that will be the case, but that it might be a problem. Is this a valid concern, or are there any other legitimate reasons to NOT fix it in streams? --Wez. On 02/05/02, [EMAIL PROTECTED] wrote: Hello Wez, there is a problem with file(), which is using the streams implementation. This is regarding bugs #16521 and #16708. It would be cool if you could fix this. regards, Derick -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] session.use_trans_sid and zlib.output_compression
Setting session.use_trans_sid = 1 zlib.output_compression = On results in HTML output without the Session ID attached to links, etc. Tested with PHP 4.2.0. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.3 charter and release plan
On 03/05/02, Stig S. Bakken [EMAIL PROTECTED] wrote: Here's the list of major changes, and the person I would like to invite as responsible for that part of 4.3: 2. PHP Streams (Wez) Sure, but I'm a bit limited for time over the next month. When someone has signed up for each major change, I want to get a feeling for how much work remains and make a rough internal release schedule. The PHP_4_3_0 branch will be created when everyone says their stuff is ready for full testing. One of the remaining todos for streams is making sure that the persistent sockets stuff works (pfsockopen); if there are any persistent resources gurus out there, your advice would be appreciated because there appear to be a couple of different ways of making things persistent but none of those methods are clear or documented. I'd also like to have a general consensus on the interfaces idea/RFC that I brought up recently: if the opinion is in favour then I would like to get that infrastructure in place and have the streams code make use of it: that serves two purposes - it will demonstrate how to use the interface API, and will reduce binary compatibility issues if we do decide to introduce it later on. I have already written the code for the interface API, so it's really just a matter of getting a majority vote in favour of having it in PHP. --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: feature proposal: string types
Those who pay attention to my occasional ramblings may remember that I
once suggested implementing type hints, which is a more generic
version of this. Type hints is like your string types, except that they
apply to any type.
I haven't been subscribed, so I don't remember. :-) I am certainly
open to a generalization of this, but I can't really imagine what it
means for other types than string - I'll try looking up your messages
in the archive.
For strings, I propose making an extensible (at runtime) registry of
string types (with a few built-in, at least those that I already
made); for each string type, the programmer would supply a function
that would convert it to a string type given as a parameter. The
additional performace hit (to my original proposal) shouldn't be too
great, since it would only occur when converting strings, which is a
process that the programmer would have to do anyway, just differently.
I guess the core issue here is whether adding an int to zval or
zval.value.str is worth the cost. With all the zval copying going on,
there will be a cpu overhead as well as memory.
Well, I assumed that the overhead wouldn't be too significant, but I
admit I didn't do any measurements whatsoever. Is there any existing
good benchmark, or should I just loop a million times through a few
random lines of code and measure this?
Back when Andi moved zval.value.strlen and zval.value.strval into
the str struct, thus saving 4 bytes in the zval struct, PHP 3 was
generally speeded up by 25%.
WHAT??? Well, since this would add them back again... :-(
Not sure if the PHP 4 or PHP 5 overhead will be in the same
ballpark, but it's something to think about.
Definitely. Although I love my idea, I guess I'd give it up myself if
it proves to be such a slow-down.
Of course, it could be made a compile-time configuration option, but
I don't think that's very useful. The programmer couldn't be sure
beforehand what version of the language his web-hoster will be
using... :-( (Which is a part of what I wanted to avoid by this -
eliminate comfortably one dependence on configuration: the
magic_quotes_gpc option.)
IMHO the syntax you suggest is a bit terse, what about this instead:
echo urlhttp://$host:$port/$path;;
Personally, I don't really care, and it's easy to change, so why not?
It would certainly need to allow for longer type names if it were to
be general, which I now want to implement.
As for the SQL string type, there needs to be at least two, some
databases quote ' as '', others quote it as \'.
This is set by cfg. option magic_quotes_sybase, so I don't think it's
necessary (the web-hoster should set it depending on which database
they provide; the programmer shouldn't even need to care about it).
But there could be one sql-type which follows the m_q_s setting, and
two others for each possibility.
But I would like to extend the idea beyond reformatting inserted
strings. For example, for easy soap/xmlrpc serialization, being able to
tag a value as a date or some other soap/xmlrpc-specific type is very
useful.
I know nothing about soap/xmlrpc, but... How about making a reserved
method name for objects that would - if it exists - be called when
that object should be converted to a string?
class Date {
function __to_string($type) {
# return a string with $this formatted as $type string
}
}
$date = new Date();
echo xmldate$date/date;
H...??
BTW, Python now has the possibility of inheriting classes from built-
in types, which would sure come in handy here...
BTW2, as I describe on the webpage that I announced, I wasn't able to
successfully run the self-test suite (make test). Could someone
please tell me what I am doing wrong (see the description at the
url)? Thanks.
The URL is, again: http://nebuchadnezzar.zion.cz/php_strings.php
Vaclav Dvorak ([EMAIL PROTECTED])
http://nebuchadnezzar.zion.cz/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: feature proposal: string types
IMHO the syntax you suggest is a bit terse, what about this instead: echo urlhttp://$host:$port/$path;; Looks perlish to me, I'd rather see a casting thing like this then: echo (url) http://$host:$port/$path;; I was originally thinking about casting too, but although I'm sure it could be done, I don't think it's good to have casting(-like) syntax have the effect I proposed. You see, what I proposed is having a different behaviour already on inserting the variables ($host, $port and $path in the above example would be converted to url string type) into the string. With casting, the behaviour would be to first make a normal string, and then cast it as a whole, losing the information about the inserted variables. but then you just could make it a function (or a language construct): echo url(http://$host:$port/$path;); Same argument against a function; could be a language construct, but I think it would be less intuitive - it would look like you first make a normal string and then convert it, which is not the case in my proposal. but this can break BC as those functions may be in use in scripts. Yeah, unless we give them really long and ugly names. Not sure if that's a good idea, though. ;-) But I would like to extend the idea beyond reformatting inserted strings. For example, for easy soap/xmlrpc serialization, being able to tag a value as a date or some other soap/xmlrpc-specific type is very useful. It might, but remember that PHP is not a strong typed language; somehow it feels like this is not just PHP then. PHP would not become a strong typed language. It would be... perhaps optionally sub-typed? :-) I wouldn't worry about this. Vaclav Dvorak ([EMAIL PROTECTED]) http://nebuchadnezzar.zion.cz/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: feature proposal: string types
On Fri, 3 May 2002 [EMAIL PROTECTED] wrote:
[..]
Well, I assumed that the overhead wouldn't be too significant, but I
admit I didn't do any measurements whatsoever. Is there any existing
good benchmark, or should I just loop a million times through a few
random lines of code and measure this?
Yup :)
Back when Andi moved zval.value.strlen and zval.value.strval into
the str struct, thus saving 4 bytes in the zval struct, PHP 3 was
generally speeded up by 25%.
WHAT??? Well, since this would add them back again... :-(
Not sure if the PHP 4 or PHP 5 overhead will be in the same
ballpark, but it's something to think about.
[..]
method name for objects that would - if it exists - be called when
that object should be converted to a string?
class Date {
function __to_string($type) {
# return a string with $this formatted as $type string
}
}
$date = new Date();
echo xmldate$date/date;
H...??
Please... no operator overloading. This was discussed before, and AFAIK
the consensus was a no on this.
Derick
---
Did I help you? http://www.amazon.co.uk/exec/obidos/registry/SLCB276UZU8B
Frequent ranting: http://www.jdimedia.nl/derick/
---
PHP: Scripting the Web - [EMAIL PROTECTED]
All your branches are belong to me!
SRM: Script Running Machine - www.vl-srm.net
---
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PHP 4.3 charter and release plan
Stig S. Bakken wrote: Here's the list of major changes, and the person I would like to invite as responsible for that part of 4.3: 6. PostgreSQL changes (Yasuo) Core code has not been changed much. I'm available any time. When someone has signed up for each major change, I want to get a feeling for how much work remains and make a rough internal release schedule. The PHP_4_3_0 branch will be created when everyone says their stuff is ready for full testing. pg_convert/metadata/insert/select/delete/update functions are added. If other database interfaces are going to have such functions, it would be nice to have the same API (both C and PHP). pg_last_notice works fine for non ZTS, but it does not with ZTS. This is better to be fixed before 4.3.0 at least. I have to design and implement user defined type support in pg_convert, since this may need API change. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] config.w32.h...registry configuration
IMHO, the enemy of the good is the better. We can implement the binary-dir solution in no time, and it covers 95% of the problems easily, but instead we'll be discussing perfect solutions and end up doing nothing :) My 2 agorot. Zeev At 08:03 03/05/2002, Markus Fischer wrote: Hi, but including other INI files at this stage is only of real advantage if we can also conditionally include it, no? Like, depending on the version too. How about looking for the version number in the filename too first, e.g.: php-apache-4.2.1.ini php-apache.ini php.ini ? This way it's even more less pain to have different versions installed. - Markus On Fri, May 03, 2002 at 06:54:41AM +0200, Stig S. Bakken wrote : On Thu, 2002-05-02 at 21:18, Shane Caraveo wrote: Zeev Suraski wrote: Does anybody have an opinion about this? Of course! ;) ini search order 1. PHP_BIN_DIR (\php\) 2. OS_DIR (\winnt\) To fix the ini issue we need more than just this. The best I can come up with right now is: 1. implement bang line parsing. This way, a specific script can define what ini file it wants to use. It should only be available in CGI/CLI systems. 2. add support for -c to use filenames in addition to paths. This way a single directory can contain multiple different config files. 3. have sapi modules (dll's) detect their directory so that server modules can correctly define where the ini file is for a particular installation. 4. For web servers, allow ini filenames to be php-domain.com.ini (or something like that) and have sapi modules look for that first if SERVER_NAME is available. 5. Implement 'override' ini files, which basicly behave the same as .htaccess. Use of these is settable in the 'global' ini file. They exist in the same directory as the script itself, and are read recursivly through the parent directory structure to some root (web root). This of course would be cached in persistent systems, CGI/CLI users would probably not want to use this feature. Some of the above will rely on the OS security being configured correctly so that people cannot access each other's ini files, but that is not the responsibility of PHP to handle (though it could be documented to some extent). I think we should add: 6. Implement include_ini directive 7. Look for php-SAPI.ini first, and php.ini if not found (this may double the disk activity, if that's acceptable). - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- Please always Cc to me when replying to me on the lists. GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc Mind if I MFH ? What QA did you do on it? the usual? ah... none :) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] A better strlcat()
To make it clear, this *WAS* a joke :) At 04:36 03/05/2002, Zeev Suraski wrote: At 03:58 03/05/2002, Preston L. Bannister wrote: Heh - there's a question :). Looking at the two implementations, which do you think you better understand (with complete certainty), and which would you be willing to (say) bet your life on? Are you implying that cryptic pointer arithmetic isn't just as crystal clear as mere simple functions? What kind of a C programmer are you? Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.3 charter and release plan
Hello Stig, Why you lose Make everything on the language-level independent of your locale settings. from TODO list ? This is very critical i think. If used locale with decimal separator like `,`, many script will working wrongly. SSB 1. New build system (Sascha) SSB 2. PHP Streams (Wez) SSB 3. Command-line SAPI installed by default (Edin) SSB 4. PEAR integration including PECL builder (Stig) SSB 5. MySQL changes (Zak) SSB 6. PostgreSQL changes (Yasuo) SSB 7. DOMXML changes? (Christian) Best regards, Andrew Sitnikov e-mail : [EMAIL PROTECTED] GSM: (+372) 56491109 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] A better strlcat()
On Fri, 3 May 2002, Zeev Suraski wrote: To make it clear, this *WAS* a joke :) But your quote was already saved and published :) Derick At 04:36 03/05/2002, Zeev Suraski wrote: At 03:58 03/05/2002, Preston L. Bannister wrote: Heh - there's a question :). Looking at the two implementations, which do you think you better understand (with complete certainty), and which would you be willing to (say) bet your life on? Are you implying that cryptic pointer arithmetic isn't just as crystal clear as mere simple functions? What kind of a C programmer are you? Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php --- Did I help you? http://www.amazon.co.uk/exec/obidos/registry/SLCB276UZU8B Frequent ranting: http://www.jdimedia.nl/derick/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] config.w32.h...registry configuration
At 07:51 03/05/2002, Stig S. Bakken wrote: Edin and I were discussing ini files on IRC last night and the same idea came up. With the exact same syntax too, actually. This is divine proof that the include_ini is good and must be implemented. :-) Seriously, being able to include other ini files is a great feature, especially for hosters who will then be able to set up site-wide config files that are included from per-vhost config files, etc. You can have your cake and eat it too. We could add it. I just hope people wouldn't start demanding control structures in there to start selectively loading other files... Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.3 charter and release plan
At 08:17 03/05/2002, Stig S. Bakken wrote: Does this organization of the 4.3 release sound reasonable? Yep. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] A better strlcat()
At 13:16 03/05/2002 +0200, [EMAIL PROTECTED] wrote: On Fri, 3 May 2002, Zeev Suraski wrote: To make it clear, this *WAS* a joke :) But your quote was already saved and published :) Where? :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PHP 4.3 charter and release plan
In [EMAIL PROTECTED], Stig S. Bakken wrote: Hi, I've volunteered to RM (release master, not /bin/rm) PHP 4.3. This release will be synchronized with the public release of the PEAR (including PECL) infrastructure. This time I'd like to try partitioning the work a bit by identifying the major changes and have one person sign up as responsible for each. I will do the overall coordination and handle stuff that don't belong to these major changes. Here's the list of major changes, and the person I would like to invite as responsible for that part of 4.3: 7. DOMXML changes? (Christian) if noone else really would like to do it, i can take over this part. I don't think, there's much new stuff in domxml since 4.2 (yes, there is some, but nothing really critical), but testing all this would be a good idea, maybe adding missing functions from the DOM-Specs as well (but this depends until when we want tp release php4.3). I'm already using domxml from 4.3 on my testing machine and didn't realize any problems with it till now. christian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] A better strlcat()
On Fri, 3 May 2002, Andi Gutmans wrote: At 13:16 03/05/2002 +0200, [EMAIL PROTECTED] wrote: On Fri, 3 May 2002, Zeev Suraski wrote: To make it clear, this *WAS* a joke :) But your quote was already saved and published :) Where? :) http://www.jdimedia.nl/derick/archive.php If you have more funny quotes feel free to mail them my way :) Derick --- Did I help you? http://www.amazon.co.uk/exec/obidos/registry/SLCB276UZU8B Frequent ranting: http://www.jdimedia.nl/derick/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: rashid
contributing to pear. Stig S. Bakken [EMAIL PROTECTED] suggested me applying for cvs account -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] config.w32.h...registry configuration
From: Zeev Suraski [mailto:[EMAIL PROTECTED]] IMHO, the enemy of the good is the better. We can implement the binary-dir solution in no time, and it covers 95% of the problems easily, but instead we'll be discussing perfect solutions and end up doing nothing :) Yes, please! :) Remember KISS ... (and I'm not getting over-friendly here). In fact you can get pretty near 100% with the simple solution just by having multiple copies of the PHP executable in different directories - one for each differing configuration. On modern disks the size of PHP is insignificant, so having multiple copies is a non-issue. In fact this is an advantage. If (say) you are running multiple PHP-based web applications, each requiring different configurations, you may in fact be dependent on different versions of PHP. A good, careful sysadmin will want to upgrade one application at a time (and test!) rather than all at once, and will want each application using it's own PHP executable. IMHO the more complicated solutions aren't really needed. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] config.w32.h...registry configuration
Well, you are correct that the size of the executable is irrelevant, but having different instances of PHP means less shared pages when multiple copies are loaded. There is a definite advantage to having a single httpd binary that is the same for everyone when it comes to runtime memory usage. -Rasmus On Fri, 3 May 2002, Preston L. Bannister wrote: From: Zeev Suraski [mailto:[EMAIL PROTECTED]] IMHO, the enemy of the good is the better. We can implement the binary-dir solution in no time, and it covers 95% of the problems easily, but instead we'll be discussing perfect solutions and end up doing nothing :) Yes, please! :) Remember KISS ... (and I'm not getting over-friendly here). In fact you can get pretty near 100% with the simple solution just by having multiple copies of the PHP executable in different directories - one for each differing configuration. On modern disks the size of PHP is insignificant, so having multiple copies is a non-issue. In fact this is an advantage. If (say) you are running multiple PHP-based web applications, each requiring different configurations, you may in fact be dependent on different versions of PHP. A good, careful sysadmin will want to upgrade one application at a time (and test!) rather than all at once, and will want each application using it's own PHP executable. IMHO the more complicated solutions aren't really needed. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] resource problem, advice wanted
At 12:02 01/05/2002, Stig Venaas wrote: This is a bit involved, I'll try to explain. I'm trying to fix a problem in the LDAP extension, but not sure how best to do it. The issue is that code like $e = ldap_first_entry($ds, ldap_read($ds,$dn,objectClass=*)); $a = ldap_get_attributes($ds, $e); crashes. What happens is that ldap_read() returns a resource. After ldap_first_entry() is executed, the resource returned by ldap_read() is freed because it is not referred any more, at least it looks that way to the Zend. The destructor for that resource will free the result obtained by ldap_read(). The problem is that the resource returned by ldap_first_entry() is simply a pointer inside the data obtained with ldap_read(), but this has now been freed, so when ldap_get_attributes() tries to access it, it's already freed. The solution would be to make sure that the result resource created by ldap_read() is not freed as long as there exists entry resources created by ldap_first_entry() etc. Or that the result destructor for the resource created by ldap_read() does not free it, and have the entry destructor (created by ldap_first_entry() etc) free the memory if it is the last entry resource for that result resource. That would require some additional data structures and refcounting though. Maybe a Zend variable could be used and let Zend do the ref counting, perhaps I could increase the refcount for the result resource each time I create an entry resource, and decrease it again in the entry destructor? Anyone got some advice? If ldap_first_entry() relies on the resource that is passed onto it, then it should add a reference count to it, using zend_list_addref(). The resource ldap_first_entry returns should be responsible for this reference, and its destructor should call zend_list_delete(). Then, only when no resources need the resource returned by ldap_read(), it'll be allowed to be freed. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] config.w32.h...registry configuration
From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]] Well, you are correct that the size of the executable is irrelevant, but having different instances of PHP means less shared pages when multiple copies are loaded. There is a definite advantage to having a single httpd binary that is the same for everyone when it comes to runtime memory usage. This is true, there will be less shared pages. I *want* this! (Though I was talking about PHP and not httpd). When we ship a new version of our application to our customers, it will have been tested with a specific version of PHP. If the customer installs another application that uses PHP, and that application installs it's own version of PHP, there is some risk (if PHP were shared) then this could break our application. We really don't want our application to break! Oddly enough the customer feels pretty much the same. Given the choice of burning a bit of memory and disk space versus risking failure (and this could effect hundreds or thousands of users), the customer will gladly buy just a bit more memory :). -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] config.w32.h...registry configuration
This is true, there will be less shared pages. I *want* this! (Though I was talking about PHP and not httpd). Well, they are commonly one and the same. But I guess you are on a Windows/CGI platform? This doesn't really apply there. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] config.w32.h...registry configuration
Well, you are correct that the size of the executable is irrelevant, but having different instances of PHP means less shared pages when multiple copies are loaded. There is a definite advantage to having a single httpd binary that is the same for everyone when it comes to runtime memory usage. There is a way around this; well the majority chunk of this problem can be solved by simply making the largest chunk of php into a library, then you have tiny launching executables that live in the various directories, and each similar versioned copy of php uses the same php4.so.4.2.1 library (or similar on Winbloze (10 blue screens too many last night on 2000 and XP)). There will be even more pressure to provide BC, but it will reduce the overall memory footprint. Each executable will have its own heap and stack, but the library will be shared, and its memory will be shared. Someone was talking about making php into a shared library, this is just more incentive to do so. Joseph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] config.w32.h...registry configuration
Zeev Suraski [EMAIL PROTECTED] wrote: We could add it. I just hope people wouldn't start demanding control structures in there to start selectively loading other files... let's just hope that by then, someone realizes we already have a scanner and parser that handles such a language close at hand. :) jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Extension news: cryptopp
I can definitely look into it, although I can't guarantee any results yet, as we're about to go back into heavy development of a new app at work (which uses the extension), but hopefully I'll get some free time to put towards it. I'll let you know how things are in two weeks or so; I should have a bit of a clue by then as to how things are going to be with the new app. J [EMAIL PROTECTED] wrote: Hello, I read some of the documentation, and noticed that this API seems to be very usable for an abstraction to multiple encryption libraries. It even looks a lot like the API I had in mind for the revamped mcrypt extension. Would you be interested in figuring the best way to do it, so that we have a nice crypto API for PHP 5? regards, Derick -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] config.w32.h...registry configuration
Pierre-Alain Joye wrote: Seriously, being able to include other ini files is a great feature, especially for hosters who will then be able to set up site-wide config files that are included from per-vhost config files, etc. You can have your cake and eat it too. Sure :). A way to make this functionnality on others server than apache is a must. The php_xxx directive let admin makes a custom config per host. On IIS, iplanet, there is actually no way to do it. Not realy true, you can do it via registry. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] config.w32.h...registry configuration
Joseph Tate wrote: Well, you are correct that the size of the executable is irrelevant, but having different instances of PHP means less shared pages when multiple copies are loaded. There is a definite advantage to having a single httpd binary that is the same for everyone when it comes to runtime memory usage. There is a way around this; well the majority chunk of this problem can be solved by simply making the largest chunk of php into a library, then you have tiny launching executables that live in the various directories, and each similar versioned copy of php uses the same php4.so.4.2.1 library (or similar on Winbloze (10 blue screens too many last night on 2000 and XP)). There will be even more pressure to provide BC, but it will reduce the overall memory footprint. Each executable will have its own heap and stack, but the library will be shared, and its memory will be shared. Someone was talking about making php into a shared library, this is just more incentive to do so. Joseph Last I looked, php was a shared library, but I could just be getting old ;) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] config.w32.h...registry configuration
There's no reason to not put in the bin-dir solution now. I just would like to see an eventual full solution to the issue. Zeev Suraski wrote: IMHO, the enemy of the good is the better. We can implement the binary-dir solution in no time, and it covers 95% of the problems easily, but instead we'll be discussing perfect solutions and end up doing nothing :) My 2 agorot. Zeev At 08:03 03/05/2002, Markus Fischer wrote: Hi, but including other INI files at this stage is only of real advantage if we can also conditionally include it, no? Like, depending on the version too. How about looking for the version number in the filename too first, e.g.: php-apache-4.2.1.ini php-apache.ini php.ini ? This way it's even more less pain to have different versions installed. - Markus On Fri, May 03, 2002 at 06:54:41AM +0200, Stig S. Bakken wrote : On Thu, 2002-05-02 at 21:18, Shane Caraveo wrote: Zeev Suraski wrote: Does anybody have an opinion about this? Of course! ;) ini search order 1. PHP_BIN_DIR (\php\) 2. OS_DIR (\winnt\) To fix the ini issue we need more than just this. The best I can come up with right now is: 1. implement bang line parsing. This way, a specific script can define what ini file it wants to use. It should only be available in CGI/CLI systems. 2. add support for -c to use filenames in addition to paths. This way a single directory can contain multiple different config files. 3. have sapi modules (dll's) detect their directory so that server modules can correctly define where the ini file is for a particular installation. 4. For web servers, allow ini filenames to be php-domain.com.ini (or something like that) and have sapi modules look for that first if SERVER_NAME is available. 5. Implement 'override' ini files, which basicly behave the same as .htaccess. Use of these is settable in the 'global' ini file. They exist in the same directory as the script itself, and are read recursivly through the parent directory structure to some root (web root). This of course would be cached in persistent systems, CGI/CLI users would probably not want to use this feature. Some of the above will rely on the OS security being configured correctly so that people cannot access each other's ini files, but that is not the responsibility of PHP to handle (though it could be documented to some extent). I think we should add: 6. Implement include_ini directive 7. Look for php-SAPI.ini first, and php.ini if not found (this may double the disk activity, if that's acceptable). - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- Please always Cc to me when replying to me on the lists. GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc Mind if I MFH ? What QA did you do on it? the usual? ah... none :) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] config.w32.h...registry configuration
Pierre-Alain Joye wrote: Seriously, being able to include other ini files is a great feature, especially for hosters who will then be able to set up site-wide config files that are included from per-vhost config files, etc. You can have your cake and eat it too. Sure :). A way to make this functionnality on others server than apache is a must. The php_xxx directive let admin makes a custom config per host. On IIS, iplanet, there is actually no way to do it. Not realy true, you can do it via registry. Do you a link where I can find info about how to use the registry ? I believe this feature is not available on Iplanet, especially on Solaris system. For the same reasons wrote in the last rasmus post, the virtual server server on iplanet is really not a good solution, performances are really bads. pa -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] config.w32.h...registry configuration
At 17:24 03/05/2002, Jim Winstead wrote: Zeev Suraski [EMAIL PROTECTED] wrote: We could add it. I just hope people wouldn't start demanding control structures in there to start selectively loading other files... let's just hope that by then, someone realizes we already have a scanner and parser that handles such a language close at hand. Yes and no - I actually wrote up a paragraph suggesting a switch to PHP, but thinking about it for a bit, it appears to be just too messy, with too many chicken and egg problems. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Another addition to session-module ... while were on topic
a better solution, in my opinoin, is some sort of grouping mechanism. this way i can set up n different session groups. every session in a group shares a set of variables so the have their own scope. i can register a session in m groups, so my session gets access to all variables of the groups, i registered it to. The session itself has a local scope itself, so i can have private variables and variables of different scopes Regards, Michael Brad Lafountain [EMAIL PROTECTED] schrieb im Newsbeitrag [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Yeah it was disscuessed that the session modules could define and handle $_APP so that would be globals for all sessions. a work around would be to do something like this $oldsession_id = sessoin_id(); session_id(1); session_start(); $var = $_SESSION['var']; session_desetroy(); session_id($oldsesion_id); session_start(); echo $var . $_SESSION['local_var']; (i didn't run this code might not work logicall it does tho) it would be much cleaner to do session_start(); echo $_APP['var'] . $_SESSION['local_var']; and allowing the session modules to handle the $_APP (files/mm/msession) variable. but you bring up a good point.. globals per 'mode'. not just 'loggged_in' but.. you could have many 'modes' that you would want globaly scoped data assoicated with them. but you could do something like this too... $_APP['logged_in'] = array(some, global, data); So i guess what im saying... if $_APP global was added then it would also solve your other 'scope'. - Brad --- Dan Hardiker [EMAIL PROTECTED] wrote: While were talking about session advancement... has anyone ever thought of adding shared sesssions? Consider the following scenario: I have 3 sets of variables: 1. Global Scoped - Variables accessed and altered by anyone entering my site. EG: a currently online array which stores the a list of active users 2. Logged in Scoped - Variables accessed by *anyone* logged in. EG: if you cache the database stuff in a session then if one user updates the cache the often you want all the logged in users to see that change without having to requery the db 3. Individual Scope - Variables specific to this user (eg: whats my name, my last ip, when did I last do anything meaningful). Being able to split those scopes up into separate variables would be great and being able to do something along the lines of: $session-global = array of global variables $session-loggedin = 2nd scope $session-personal = personal variables and then have the session module manage those 3 sessions individually. In short - it would be cool if a script could (easily) have access to a multitude of sessions and keep them segregated. -- Dan Hardiker [[EMAIL PROTECTED]] ADAM Software Systems Engineer First Creative Ltd -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php __ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Another addition to session-module ... while were on topic
btw, i'm writing a session module like this in php atm, but it would be much better, if it were programmed directly into the core. I'm i total C-Newbie, so i'm not able to do it myself. If anyone is interested in doing it, i'd highly appreciate it. Regards, Michael Michael Virnstein [EMAIL PROTECTED] schrieb im Newsbeitrag [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... a better solution, in my opinoin, is some sort of grouping mechanism. this way i can set up n different session groups. every session in a group shares a set of variables so the have their own scope. i can register a session in m groups, so my session gets access to all variables of the groups, i registered it to. The session itself has a local scope itself, so i can have private variables and variables of different scopes Regards, Michael Brad Lafountain [EMAIL PROTECTED] schrieb im Newsbeitrag [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Yeah it was disscuessed that the session modules could define and handle $_APP so that would be globals for all sessions. a work around would be to do something like this $oldsession_id = sessoin_id(); session_id(1); session_start(); $var = $_SESSION['var']; session_desetroy(); session_id($oldsesion_id); session_start(); echo $var . $_SESSION['local_var']; (i didn't run this code might not work logicall it does tho) it would be much cleaner to do session_start(); echo $_APP['var'] . $_SESSION['local_var']; and allowing the session modules to handle the $_APP (files/mm/msession) variable. but you bring up a good point.. globals per 'mode'. not just 'loggged_in' but.. you could have many 'modes' that you would want globaly scoped data assoicated with them. but you could do something like this too... $_APP['logged_in'] = array(some, global, data); So i guess what im saying... if $_APP global was added then it would also solve your other 'scope'. - Brad --- Dan Hardiker [EMAIL PROTECTED] wrote: While were talking about session advancement... has anyone ever thought of adding shared sesssions? Consider the following scenario: I have 3 sets of variables: 1. Global Scoped - Variables accessed and altered by anyone entering my site. EG: a currently online array which stores the a list of active users 2. Logged in Scoped - Variables accessed by *anyone* logged in. EG: if you cache the database stuff in a session then if one user updates the cache the often you want all the logged in users to see that change without having to requery the db 3. Individual Scope - Variables specific to this user (eg: whats my name, my last ip, when did I last do anything meaningful). Being able to split those scopes up into separate variables would be great and being able to do something along the lines of: $session-global = array of global variables $session-loggedin = 2nd scope $session-personal = personal variables and then have the session module manage those 3 sessions individually. In short - it would be cool if a script could (easily) have access to a multitude of sessions and keep them segregated. -- Dan Hardiker [[EMAIL PROTECTED]] ADAM Software Systems Engineer First Creative Ltd -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php __ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.3 charter and release plan
On Fri, 2002-05-03 at 13:17, Andrew Sitnikov wrote: Hello Stig, Why you lose Make everything on the language-level independent of your locale settings. from TODO list ? This is very critical i think. If used locale with decimal separator like `,`, many script will working wrongly. SSB 1. New build system (Sascha) SSB 2. PHP Streams (Wez) SSB 3. Command-line SAPI installed by default (Edin) SSB 4. PEAR integration including PECL builder (Stig) SSB 5. MySQL changes (Zak) SSB 6. PostgreSQL changes (Yasuo) SSB 7. DOMXML changes? (Christian) Huh, are you saying PHP _is_ locale-dependant? I was not aware of that (but then again I always use the C locale). - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.3 charter and release plan
On Fri, 2002-05-03 at 11:40, Wez Furlong wrote: On 03/05/02, Stig S. Bakken [EMAIL PROTECTED] wrote: Here's the list of major changes, and the person I would like to invite as responsible for that part of 4.3: 2. PHP Streams (Wez) Sure, but I'm a bit limited for time over the next month. That's fine. Predictability is the key. When someone has signed up for each major change, I want to get a feeling for how much work remains and make a rough internal release schedule. The PHP_4_3_0 branch will be created when everyone says their stuff is ready for full testing. One of the remaining todos for streams is making sure that the persistent sockets stuff works (pfsockopen); if there are any persistent resources gurus out there, your advice would be appreciated because there appear to be a couple of different ways of making things persistent but none of those methods are clear or documented. I'd also like to have a general consensus on the interfaces idea/RFC that I brought up recently: if the opinion is in favour then I would like to get that infrastructure in place and have the streams code make use of it: that serves two purposes - it will demonstrate how to use the interface API, and will reduce binary compatibility issues if we do decide to introduce it later on. I have already written the code for the interface API, so it's really just a matter of getting a majority vote in favour of having it in PHP. +1 from me. I think it'd be nice to play with it for a while to collect experience that can be used to make interfaces perfect in PHP 5 :-) - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFI: Request for Interfaces
At 03:04 04/05/2002, Zeev Suraski wrote: One thing that I'm personally don't really understand note to selfreread entire paragraph after rewriting parts of it/note to self -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
