[PHP-DEV] Re: OO in PHP5 (was zend_API.c on php-dev)
andrei's point: extensions should stick to either functional or oo API PEAR wrappers can be provided my point: extensions should expose both APIs (if desired) can be done by aliasing functions to class methods - no duplicate c code when called as function - print warning when called as method - throw exception What do you guys think of this? I would argue that having two different methods to do the same thing only leads to increased complexity and confusion. Sure, some people like it one way and some people another, but having a standard way of doing things is, IMHO, better. Bye, Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5 mailing list
I am very happy that the mailing-list tab on the PHP main web site doesn't include it yet. I'd prefer only people who are active in the developer's community (i.e. php-dev, php-qa) to be part it. Was there ever a discussion of introducing a more formal organisation into the development process (I might have missed it, having actively followed php-dev for one year only)? Something along these lines: http://httpd.apache.org/dev/guidelines.html I think that a few rules would benefit the PHP community, and allow us to spend the resources we have more wisely. Bye, Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: ivanr
I want to bring my involvement with PHP to the next level: bug fixing, documentation, annotated manual, working on new features to enhance security. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] downgrade undefined function from fatal error
John Coggeshall wrote: There is absolutely no reason why you cannot simply include your functions in your scripts Erm, to avoid manual work? There is no reason whatsoever to include files manually. Right now you must pre-load every single class you intend to use in the application. This may or may not be a problem, depending on the size of the application, since the engine must parse hundreds of KB of code. I use classes for everything and I would prefer to have one file per class, and to load classes on demand. Makes maintenance much easier. The patch for this is trivial. It was made a while ago and it seems that it still works (just tried it with 4.2.3) http://www.webkreator.com/php/configuration/automatic-php-class-loading.html -- Ivan Ristic, http://www.webkreator.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] $php_errormsg not populated
I have noticed that $php_errormsg is not populated
for all types of errors. The code below is from main/main.c.
Do you think that we can safely switch places for parts one
and two? If we do $php_errormsg will be populated before
bailing out, and this inconsistency will be sorted.
-- pt 1 --
/* Bail out if we can't recover */
switch (type) {
case E_CORE_ERROR:
if(!module_initialized) {
/* bad error in module startup - no way we can live
with this */
exit(-2);
}
/* no break - intentionally */
case E_ERROR:
/*case E_PARSE: the parser would return 1 (failure), we can
bail out nicely */
case E_COMPILE_ERROR:
case E_USER_ERROR:
if (module_initialized) {
zend_bailout();
return;
}
break;
}
-- pt 2 ---
/* Log if necessary */
if (PG(track_errors) EG(active_symbol_table)) {
pval *tmp;
ALLOC_ZVAL(tmp);
INIT_PZVAL(tmp);
Z_STRVAL_P(tmp) = (char *) estrndup(buffer, buffer_len);
Z_STRLEN_P(tmp) = buffer_len;
Z_TYPE_P(tmp) = IS_STRING;
zend_hash_update(EG(active_symbol_table), php_errormsg,
sizeof(php_errormsg), (void **) tmp, si
}
---
--
Ivan Ristic, http://www.webkreator.com
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Cookie Session Problem
The problem i'm having is that the session id is showing up in the url when a user moves to the next page in the site, but then after that it stop showing up in the url (the way it should be). I don't want the session id (periodically) showing up in the url this causes me problems on certain things. Why does this happen? It is a feature to support users that do not have cookies or have cookies disabled. The sessionid is showing only on the first page access; once PHP establishes that the user supports cookies it will stop changing URLs. It is documented here: http://www.php.net/manual/en/ref.session.php You can turn it off by setting session.use_trans_sid parameter to off (btw, it is off by default). Bye, Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: persistent java virtual machine under PHP
From the PHP point of view, you can get problems with persistent database connections on a very high load site, that's true. But that's about the only problem. Sure, you can't build a persistent storage of information in the server but that's a minor issue. It's not a minor issue. Using persistent objects that are expensive to aquire is a common pattern, which can improve performance significantly. The above scenario prevents exactly that. Right, but you can still use shared memory, or, you can store persistent objects onto the filesystem. We've done the later with satisfactory results. I guess this is more of an apache issue then a PHP issue. I'd have to look more closely at the apache sources to investigate further. Apache 2 resolves this problem. You can configure it to run multithreaded. Still, the issue of having a stable PHP remains. Plus, PHP has no mechanisms to handle multithreaded access from user space, you would have to use shared memory locks or file system locks. Bye, Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: persistent java virtual machine under PHP
There is a servlet which accepts requests and uses native code from libphp4.so to execute them. At the same time, the Java extension is used to provide access to Java objects from PHP itself. but the ext/java as it is would not be suitable, as it would spawn new JVMs every once in a while (thus it would use a different JVM then the one that called the PHP page). No, I have been told (by someone, I do not remember) that if you use PHP as a servlet ext/java would use the same JVM. I haven't check to see whether that is correct. Where can I find documentation for calling libphp4.so? How do I execute a PHP script by calling some functions in libphp4.so? /sapi/servlet Bye, Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: persistent java virtual machine under PHP
What I'm looking for is that the JVM would not be discarded on a regular basis, but it would remain persistent. I do not think that is possible, unless PHP engine itself is contained within a single process (and runs multithreaded). Which it isn't (under Apache 1.x , at least). You can perhaps try to use it the other way around, have PHP run inside a Java VM. You can also try to get the source code for the Java extension from the CVS as some patches have been submitted recently. Ideal solution for Java integration would be to have a single JVM running as a separate process, and to have the PHP communicate with it using some efficient protocol. This can be done right now although I do not think that the current Java extension works like this. However... I have heard (can someone confirm this, please) that ZE2 handles foreign (i.e. non-PHP) object nicely and that you will be able to have classes and objects that feel like normal object but would in fact execute outside the engine. If the above is correct I would prefer to wait for ZE2 in order to integrate my PHP and my Java. On a similar note, is someone working on a ZE2-compatible extension at the moment? I might be interesting to work on it. There is one relevant project, see http://www.vl-srm.net (integrates PHP and PHP, not PHP and Java, but the method is the same). Bye, Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: persistent java virtual machine under PHP
How is a persistent database connection handled then? e.g. in the mysql module? Apache 1.x pre-creates a number of server processes. Each process handles a certain number of requests (one at a time), and then dies. It is then replaced with an another server process. The number of processes can vary depending on the load and the configuration. Database connections (and other resources) are persistent on the per-server-process level. What this means that an open connection in one server process cannot be reused from within another server process. When using PHP with IIS, on the other hand, you only have one process and only one set of persistent connections. Since creating a 100% thread safe PHP (PHP meaning the core engine plus the libraries) is practically impossible, I would say that PHP will go the FastCGI route, even on Windows. Bye, Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: bug of the day: $this
Balazs Nagy wrote: Hi, $this stays defined when an instantatiated member function calls a non-instantiated member function. Correct. I actually find it quite interesting. :) It can be useful at times, I have used it in my libraries as a feature. There is an interesting article on the subject: http://www.advogato.org/article/470.html -- Ivan Ristic, http://www.webkreator.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Handling fatal and parse errors (just a link :)
Hi, since we are not going to patch PHP to support redirection on fatal errors or the 500 error code, here is a link to the technique you can use (works with 4.2.3) to handle these errors. I already posted a note about this but discovered that the old approach no longer works, and I had to rewrite it. The example code can be downloaded from the article. http://www.webkreator.com/php/configuration/handling-fatal-and-parse-errors.html -- Ivan Ristic, http://www.webkreator.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: bug of the day: $this
$this stays defined when an instantatiated member function calls a non-instantiated member function. Correct. I actually find it quite interesting. :) It can be useful at times, I have used it in my libraries as a feature. There is an interesting article on the subject: http://www.advogato.org/article/470.html Now, please tell me how can you decide whether the member function is called as an object element (eg. $obj-func()) or as a class element (eg. class::func()). You mean from the function itself? You can't, as far as I can tell. That is why this works best if you have a helper class with all static methods. Once nice example that comes to mind is a method that persists objects to the database. But never mind that, I am not trying to justify the existence of this quirk so there is no point in discussing it. Basic functionality is killed with this so-called feature. Although I did use it as such, I wouldn't actually call this a feature, and would prefer to have it removed from ZE2. Bye, Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Redirect on Error (not localisation)
Anyway... So what of my actual patch we were discussing at some point? I never got a real answer as to if it would be suitable to commit. I have changed the subject of the message in an effort to separate the discussion on the Redirect on Fatal Error feature (the subject of this email) from the localisation discussion. ... As a reminder, we are discussing a patch that will redirect the user to another page when a fatal or a parse error occurs (parse errors can be caught with lint, fatal can't). The redirection will allow developers to: * Show a decent page to the user (instead of letting them see a blank or incomplete page) * Send a message to themselves that something strange has happened (allowing them to react quickly, instead of having to install log watch software for notification purposes (and many people cannot do that as they do not have control over the servers)) As far as I am aware, there is not a single reason not to have this feature. Some people seem not to like it, but that is fine; with no performance or stability risks, if you don't want to use the feature - you won't be affected. On the other hand, I will be extremely happy to have it under my belt as yet another tool I can use to make my software run better. Please don't tell me that I wouldn't need this feature if I programmed perfectly. Errors happen all the time, no matter what you do trying to prevent them. Bye, Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error reporting for PHP5
Sorry to jump in the middle of a conversation, but I just wanted to say that I personally use trigger_error() quite often. Me too, I use it for warnings, notices, and errors that cannot be remedied. In my programs I also simulate custom error codes. The first part of the error string looks something like [error.code] Message and I parse this later and act upon it. The site I maintain has a nice custom error handler which logs the error and emails the admins the error details + var dumps, etc. Absolutely. I often use trigger_error() in my code because it allows me to treat certain situations the same as a PHP generated error. Of course, I suppose I could just call my custom error handler directly but that seems less elegant...just MHO. The way with trigger_errors is better because you can at any time turn the custom error handler off, and everything would still work. Bye, Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
John Coggeshall wrote: If I hacked on the source a bit and got this redirect-error thing working, would it Be perhaps worthy of a commit? +1 Bye, Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
Edin Kadribasic wrote: On Thursday 21 November 2002 08:04, Derick Rethans wrote: I still think that an included file just should fail hard and I just dont like this kind of obfucsication. I agree with this 100%. It is IMHO a complete waste of time trying to handle parse errors gracefully. Most solutions proposed in this thread are either server specific or would have an impact on normal php operation (would require output buffering, etc.). And in the real life you sometimes must change things live on the server, in the middle of the night. If you make a mistake then, and we all do, you will go to sleep without realising that the app/web site no longer works properly. I use logwatch for this at the moment, but that is, IMHO, a very, very, clumsy solution. Bye, Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
Mike Robinson wrote: In Real Life [Patent Pending], if you cripple your production site in the middle of the night then go to bed, you won't have to worry about any of this because you'd be unemployed in the morning. I assume then that you run regression tests for your web sites after every change? Or stay awake throughout the night? Or not make mistakes at all and so you have nothing to fix at nights? :)) Bye, Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
We were talking about parse errors here. php -l before you put it life should be enough for that. And yes, I run that before 'cvs commit'. Well, I am afraid that it is not that simple, as there are other fatal errors that cannot be caught and where lint is useless. For example, $object-wrong_function_name() is a fatal error. Since I am no perfect and make mistakes all the time, I would like my programming environment of choice to help me as much as possible. Also, from a management point of view (I manage programmers), what you are describing there can work in some cases but what if a programmer forgets/is-too-lazy to to that? I don't want to wait for the next morning to know about it. Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: error reporting for PHP5
I will start laying out some my thoughts to hopefully get a discussion towards working on the complete error reporting logic. I had an extensive experience implementing custom errors, so approve or disapprove my ideas. I like your ideas too, but some of your suggestions need to be compared to the exception mechanism, to avoid duplicated effort. I have been following the thread about error reporting thing and, I think, it is all going off route. While I do agree that the error handling mechanism needs to be enhanced, none of your suggestions are directly related to the error handling discussion and the patch. I think we should finish with the patch discussion first so that we can later proceed to more complex issues. Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: error reporting for PHP5
Throwing this idea on another time can sound rush. Rright now, when our heads are occupied analysing error reporting, this can result being more productive, IMO. And, it is till related anyway. I don't mind, I just don't want the patch forgotten :) Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] URL for segfaults
Steven Roussey wrote: No. And I wish access_log logged requests at the beginning of a request and had the child pid. It would be very easy to write a custom module to log that at the beginning of the request. Would that help? Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] URL for segfaults
Steven Roussey wrote:
Yes. Ideally such that you can grep for the failed URLs. I can see this
as being very helpful to a lot of people. Debug modes don't work for
production servers and it is only there that it is showing itself.
BTW - Easy for you maybe!
Don't take my word, have a look at it! :)
Ivan
#include httpd.h
#include http_config.h
#include http_request.h
#include http_protocol.h
#include http_core.h
#include http_main.h
#include http_log.h
module MODULE_VAR_EXPORT earlylog_module;
static int el_log(request_rec *r) {
ap_log_rerror(APLOG_MARK, APLOG_NOTICE|APLOG_NOERRNO, r, mod_earlylog: [%s]
%s, r-hostname, r-the_request);
return DECLINED;
}
module MODULE_VAR_EXPORT earlylog_module = {
STANDARD_MODULE_STUFF,
NULL, /* module initializer */
NULL, /* create per-dirconfig structures */
NULL, /* merge per-dirconfig structures */
NULL, /* create per-server config structures */
NULL, /* merge per-server config structures */
NULL, /* table of config file commands */
NULL, /* [#8] MIME-typed-dispatched handlers */
NULL, /* [#1] URI to filename translation*/
NULL, /* [#4] validate user id from request */
NULL, /* [#5] check if the user is ok _here_ */
NULL, /* [#3] check access by host address */
NULL, /* [#6] determine MIME type*/
NULL, /* [#7] pre-run fixups */
NULL, /* [#9] log a transaction */
NULL, /* [#2] header parser */
NULL, /* child_init */
NULL, /* child_exit */
el_log /* [#0] post read-request */
};
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
James Cox wrote: Also, from a management point of view (I manage programmers), what you are describing there can work in some cases but what if a programmer forgets/is-too-lazy to to that? I don't want to wait for the next morning to know about it. if a programmer is too lazy to test, fire them. there are plenty more better ones to hire. That's very funny! :) You are oversimplifying a complex issue. Real life is a series of compromises. But let us not stray anymore, this is not the subject of the discussion. If you want, you can still email me privately. Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
John Coggeshall wrote: |I know this is possible now, but not within the error handling |function of PHP, or without setting a custom error handler. Well, it's not really possible now -- a E_PARSE won't get thrown to a custom PHP handler, it'll just die with a parse error. It is possible. Not pretty but still possible :) You can use a series of hacks to make PHP behave and allow you to intercept an fatal error, and extract the error message. In short: * You use auto_append to append a short PHP file that only sets a flag to true * You install a custom error handle to handle normal errors. * You need to turn the output buffering on. * You register a shutdown function the checks the flag; if the flag is set to false - you have a fatal error on your hands. In that case you need to clear the output buffer but not before you extract the fatal error message (you need to have display_errors set to on). Then you can forward the fatal error to your normal error handler for processing. The full explanation is available here: http://www.webkreator.com/php/configuration/foolproof-php-handling-2.html I do not recall the version I used and I haven't checked whether this still works with recent releases. It did work at the time. Bye, Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
Create a configuration directive error_handler which accepts one of Two values... Either a PHP script (like auto_prepend) which is And how about that we change PHP so that it changes the status of the response to 500 on a fatal error? Then you would be able to use the Apache directive ErrorDocument 500 /handle-my-errors.php to deal with them. You would have to use output buffering, of course, but using output buffering is the only way to shield your users from errors anyway. Bye, Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
The problem with this is that the 500 error does not provide any information about the error. To the user, no. I wouldn't want users to see low level error messages anyway. Since standard error handlers can catch normal messages, the fact that a 500 error has occured means that something bigger is wrong and you have to go and fix it anyway. Then you can look the error message in the log file and see what the problem was. Also, the message will probably be parse error at line XXX anyway :)) You would probably keep this off during the development phase, in which case messages will appear directly on screen. Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] code profiler
i am searching for a PHP code profiler DBG (http://dd.cron.ru/dbg/sshot.php) seems to be doing what you need. The link points to the screenshots page, and some screenshots show the profiler in action. -- Best regards, Ivan Ristic, Chief Technology Officer DataGate Network Solutions Ltd. - http://www.datagate.net Tel: +44 8700 119090, Fax: +44 8700 119080 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] REPOST: Class Autoloading [PATCH]
The second problem is that I don't see it working with nested classes. Is it good enough to only have this work with classes in the global scope? I am not really familiar with nested classes; is it because you don't know the name of the file in which a nested class is located? If so, I would say that trying to accommodate that would be an overkill. In any case, the programmer using nested classes can always write the __autoload() function that will be smart enough. The problem is that if you have MyClass1::MyClass2::MyClass3 then MyClass3 is looked up in the result of MyClass2 being looked up in MyClass1. If the lookup fails I can't tell __autoload() the path. The only think I could do is possibly pass it the result of MyClass2 being looked up in MyClass1 and MyClass3. The question is if people will manage to handle this. I think it might be complicated and it might be best not to go in this direction. I see the problem. But I would also like to play with it to understand it better. Why don't you add the feature so that we can test it, and we will remove it later if it prooves unusable? -- Ivan Ristic, [EMAIL PROTECTED] [ Weblog on PHP, Software development, Intranets, and Knowledge Management: http://www.webkreator.com ] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] REPOST: Class Autoloading [PATCH]
First of all I'd prefer it to call a predefined callback called __autoload() if a class is not found. I do not have a problem with the predefined name. However, unserialize is already using the ini setting for the same thing, and it would be a shame to introduce an inconsistency. Can we obey the ini setting if it is there, and call __autoload() if it isn't (i.e. introduce __autoload as a default value for the ini parameter)? The second problem is that I don't see it working with nested classes. Is it good enough to only have this work with classes in the global scope? I am not really familiar with nested classes; is it because you don't know the name of the file in which a nested class is located? If so, I would say that trying to accommodate that would be an overkill. In any case, the programmer using nested classes can always write the __autoload() function that will be smart enough. -- Ivan Ristic, [EMAIL PROTECTED] [ Weblog on PHP, Software development, Intranets, and Knowledge Management: http://www.webkreator.com ] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] REPOST: Class Autoloading [PATCH]
Okay, I guess I can live with it :) Andi Is there anyone else who would like to comment on the patch? http://www.webkreator.com/download/class_autoload.patch Or can we have it committed? -- Ivan Ristic, [EMAIL PROTECTED] [ Weblog on PHP, Software development, Intranets, and Knowledge Management: http://www.webkreator.com ] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] REPOST: Class Autoloading [PATCH]
Several days ago I posted a simple patch to the Zend Engine, to support automatic class loading. The code is almost completely copied from the existing auto-loading mechanism for the unserialize function. Basically, a userland function is called whenever a non-defined class is called. The function can then find the class, and in that case the execution can continue as normal. Can someone please review the patch and then commit it to the CVS? This is the link to the original email and to the patch itself: http://marc.theaimsgroup.com/?l=php-devm=102311009628061w=2 -- Ivan Ristic, [EMAIL PROTECTED] [ Weblog on PHP, Software development, Intranets, and Knowledge Management: http://www.webkreator.com ] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REPOST: Class Autoloading [PATCH]
I believe this has been discussed in the past and not ack'd, please read the php-dev archives... I tried and I tried but I couldn't find a discussion on anything similar on the mailing list. The code I sent is *already* in use, and has been in use for some time now. Take a look at this message from November 2001: http://marc.theaimsgroup.com/?l=php-devm=100687224711738w=2 I didn't introduce anything new, so if it was OK then it should be OK now. Also, the code cannot affect the people that are not using the feature so I do not think that there will be any kind of impact on the existing user base. This feature makes it possible to have one class per file and not to worry about inclusion at all. It becomes especially useful when used together with products such as Zend Accelerator, where files are cached (and you do not have to worry about a large number of small files). -- Ivan Ristic, [EMAIL PROTECTED] [ Weblog on PHP, Software development, Intranets, and Knowledge Management: http://www.webkreator.com ] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] WHAT is PHP's vision????
I believe that the following would greately benefit PHP: * Devise a kind of formalised process to document problems, new requirements, areas where PHP can be improved, decisions, projects, so on and so on. * Support this process with a collaborative web site where people would be able to see what is happening in the community, who is doing what, and where the help is needed. The way I see it, everyone has an itch to scratch, and we need to have all people with the same itch united. Would this be used if it existed? -- Ivan Ristic, [EMAIL PROTECTED] [ Weblog on PHP, Software development, Intranets, and Knowledge Management: http://www.webkreator.com ] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] WHAT is PHP's vision????
I don't think a dictator is needed. Even if I or someone else was to dictate that PHP was a web-only scripting language, do you really think that people would stop working on and using PHP for other things? The point of a plan/dictator is to provide a sense of direction. Some people will still do things that are not in the plan, but with a well defined vision you will catch those developers that would not contribute otherwise. If people do not understand the big picture then they will solve their problems in a way that will work only for them, and not for other users of PHP. PHP has been really good in the past where the effort was small enough for one person to handle or where people organised themselves to work in a team. The whole XML/XMLRPC/SOAP issue is a very good example of this. The marketing aspect of a vision must not be neglected either. If you go to the main web site, you can't find a single word about what is going to happen next. Now, if I am to choose PHP for my business I want to know that -- Ivan Ristic, [EMAIL PROTECTED] [ Weblog on PHP, Software development, Intranets, and Knowledge Management: http://www.webkreator.com ] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] WHAT is PHP's vision????
[oops, I sent the message before finishing it] for other users of PHP. PHP has been really good in the past where the effort was small enough for one person to handle or where people organised themselves to work in a team. The whole XML/XMLRPC/SOAP issue is a very good example of this. ...very good example of how a lot of effort has been wasted with multiple implementations of the same thing. The ability to choose is a good thing but we do not have spare programming resources to allow this. The marketing aspect of a vision must not be neglected either. If you go to the main web site, you can't find a single word about what is going to happen next. Now, if I am to choose PHP for my business I want to know that ...PHP lives and that new requirements/problems that arise will be properly addressed by someone who oversees the whole thing and thinks about my needs (I am talking about the global userbase, as very few people contribute to the core PHP effort). -- Ivan Ristic, [EMAIL PROTECTED] [ Weblog on PHP, Software development, Intranets, and Knowledge Management: http://www.webkreator.com ] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] WHAT is PHP's vision????
Hmm, this sounds somewhat like evolutional model vs. non-evolutional, but perfectly planned. At least for me all evolutional development attempts work much better. I need three, four versions until I've reached production level, so there's nothing wrong for me even with totally different developments. I do not believe in plans carved in stone either. Plans can and should change but I would argue that simply having a plan is much more efficient than not having it. -- Ivan Ristic, [EMAIL PROTECTED] [ Weblog on PHP, Software development, Intranets, and Knowledge Management: http://www.webkreator.com ] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Class autoload patch
I have written this small patch to support class autoloading. It
is written in the spirit of the unserialize callback (see
http://www.php.net/manual/en/function.unserialize.php) and uses
the same callback function.
Can someone with write access to CVS please commit the patch?
I assume that this is a safe thing to do because the same
mechanism is already in use in the production code.
Example:
function _autoload($classname) {
@include_once(class.$classname.php);
}
ini_set(unserialize_callback_func, _autoload);
// the following will work even if class X has
// not be defined so far
$x = new X();
--
Ivan Ristic, [EMAIL PROTECTED]
[ Weblog on PHP, Software development, Intranets,
and Knowledge Management: http://www.webkreator.com ]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Class autoload patch
If you are having problems with the attachment from my
previous email, the patch is available for download here:
http://www.webkreator.com/download/class_autoload.patch
I have written this small patch to support class autoloading. It
is written in the spirit of the unserialize callback (see
http://www.php.net/manual/en/function.unserialize.php) and uses
the same callback function.
Can someone with write access to CVS please commit the patch?
I assume that this is a safe thing to do because the same
mechanism is already in use in the production code.
Example:
function _autoload($classname) {
@include_once(class.$classname.php);
}
ini_set(unserialize_callback_func, _autoload);
// the following will work even if class X has
// not be defined so far
$x = new X();
--
Ivan Ristic, [EMAIL PROTECTED]
[ Weblog on PHP, Software development, Intranets,
and Knowledge Management: http://www.webkreator.com ]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] WHAT is PHP's vision????
PHP is for the most part written by volunteers who contribute code/extensions which are based on their needs or were solutions to the problems they've come across when working with PHP. You cannot tell those people what to do, certainly the PHP Core Developers can reject the patch, but that's about it. If people want to become a part of a larger entity then they must give up some of their individuality. This is happening already but only for low level issues (e.g. case sensitivity). I am arguing to do the same for other important aspects of the PHP technology. Otherwise, PHP will be a boat where everyone paddles independently. Sure, we are moving - but where to? We should all agree that there is a really nice green island in front of us, join forces, and simply go there. -- Ivan Ristic, [EMAIL PROTECTED] [ Weblog on PHP, Software development, Intranets, and Knowledge Management: http://www.webkreator.com ] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] WHAT is PHP's vision????
Ultimately it is the job of the Core Developers to accept or decline patches, as the end user you of course can choose to compile or not compile a module you dislike. If you are diluding yourself into thinking that people will voluntarily code what they are 'told' to code, they'll do what they like/need or not do it at all. I would not say that 'telling' people is the way to go. We need leadership, and someone to sell the vision of 'better life with PHP' to people. At least from my personal experience all the work I've done involving PHP source came from having a certain need PHP could not adequantly fulfill in my mind. Agreed. But there are positive sides to Open Source: there are thousands of developers out there. Chances are, no matter where you decide to take PHP, someone will want to go there. I like working on my own, for example, but I have decided to put my efforts into PEAR because that will benefit the community more then releasing 'yet another ACME PHP libary' to satisfy my ego. Bye, Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Anyone wrote persistent variable extension?
Usage:
?php
if (!isset($_PERSISTENT['VAR'])) {
include('register_very_large_array.inc');
}
?
What would the scope of this variable be? If it is global
(as in PHP engine global) then the solution would not work
in an shared environment (and it would not be practical
for multiple applications anyway).
Ideally, there would be one copy of the variable per
application, but we need to somehow define what application is.
I think that the best approach would be to introduce a new
php configuration option, something like application_name,
and that would then define security for these kinds of
things (naturally, you won't be able to change this one from
the script :).
--
Best regards,
Ivan Ristic, Chief Technology Officer
DataGate Network Solutions Ltd. - http://www.datagate.net
Tel: +44 8700 119090, Fax: +44 8700 119080
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Anyone wrote persistent variable extension?
bool psv_register(string var_name, array values, string access_key); where var_name is variable name, values are array to regieter, key is access key for the variable. access key is unique id of an application? If so, I would still prefer the approach with the configuration variable as I if I know your access_key (no matter how complex it may be) I can always access your data. With the configuration variable you would need access to either php.ini or httpd.conf, which typically requires root access. There is one more option, it is more of a hack really, we can use the value of the session.save_path, which should be set on the per application basis anyway. bool psv_is_registered(string var_name, string access_key); Return TRUE is var_name is registered with the access_key. Are these PHP userland functions? I believe that the approach with _PERSISTENT or _APPLICATION is better as it is more transparent for the programmer. ... I would also like to add a couple of functions to lock and unlock variables, if possible. psv_lock(string var_name); Locks created on a page would always be destroyed at the end of execution of that page. psv_unlock(string var_name); ... I assume that we will be able to make whole objects persistent, no? -- Best regards, Ivan Ristic, Chief Technology Officer DataGate Network Solutions Ltd. - http://www.datagate.net Tel: +44 8700 119090, Fax: +44 8700 119080 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Anyone wrote persistent variable extension?
I need to store large static array as lookup table (read only). I think there are many applications that has relatively large static array for application configuration, etc. $_PERSISTENT is problematic, since user may store unsutable data for it. Are there problems with objects or other data structures? I am prepared to make my hands dirty in order to make persistent objects possible with PHP :) I'll create functions to register/unregister so that user can only store array that does not have any reference nor objects. Aha, now I understand the email you sent earlier :) -- Best regards, Ivan Ristic, Chief Technology Officer DataGate Network Solutions Ltd. - http://www.datagate.net Tel: +44 8700 119090, Fax: +44 8700 119080 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] class variable problem
I think it's misleading in best case. Property 'bar' *is* declared, so I think it should have an entry in class's default_properties table, even though it's not assigned a value. I agree. There is another problem: if you do not initialize a variable then it won't be listed using get_class_vars(). Now that is confusing. Can we have default values? -- Best regards, Ivan Ristic, Chief Technology Officer DataGate Network Solutions Ltd. - http://www.datagate.net Tel: +44 8700 119090, Fax: +44 8700 119080 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PROPOSAL] defense against session takeovers
The real IP address can be tracked in most cases (say, using the HTTP_X_FORWARDED header an others) but I am not really sure that we should put the logic for that in the PHP engine itself. Users can add the additional PHP code to their libraries. Anyway, you can change the session id from the PHP code itself. Still the IP of the client can change every once in a while when his DHCP lease expires ... or when they use dial-on-demand and automatic hangup as eg. provided by the linux ISDN subsystem? Do you really want client sessions to become invalid every time their ISP decides to assign them a new IP? For my system at home this could make a service unusable as it automaticly hangs up the ISDN line after 60sec without IP traffic and redials on demand (with ISDN you have connect times of 1sec, so you don't even notice you've been disconnected, but you'll notice the effect on the bill if you are charged by connection time). So my Client IP might even be different for every single request if it takes me more than a minute to read a page or fill out a form ... You got a point there. I am not arguing that this needs to be added to the engine code itself. But I do argue that site owners should at least have such a code to warn them about possible hijack attempts. It all comes to how paranoid you are. For example, a changed IP address of the client (not the proxy) can be accepted as normal, but if the USER_AGENT changes as well - now that is suspicious. Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Developer Seeking To Help
One common way is to create your patches and post them either to the php-dev list or as a comment (prefered) in the bug db, and if they are useful, the dev team will have a good reason to give you cvs access. (Use unified diff format for patches.) I have recently updated the FTP extension to include a couple of more functions (send raw command and get the raw response body), and I would like to send the patch now. Is all I need to know available in man patch? -- Best regards, Ivan Ristic, Chief Technology Officer DataGate Network Solutions Ltd. - http://www.datagate.net Tel: +44 8700 119090, Fax: +44 8700 119080 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PROPOSAL] defense against session takeovers
How about that we use the SERVER_NAME environment variable when generating session filenames? Instead of name like sess_, the name could be sess__, where is a server fingerprint? I understand that this is not foolproof (say, for applications that run on the same domain name) but it will solve the most serious cases (shared hosting solutions). -1 for this because it destroys php functionality. it makes it impossible to have multiple domains with the same sessions f.e. www1.myserver.com www2.myserver.com news.myserver.com archive.myserver.com In order to make the above work you need to put a lot of effort. Cookies sent to www1.myserver.com will not arrive to www2.myserver.com. With the default configuration, a user visiting one server and then the other will create two different sessions. You need to manually tweak session.cookie_domain to make it work. Also, URL rewriting does not work on absolute URLs, and you would have to manually append the SID to the URL to make the session span two different domains. I am saying that with a lot of work required to make the above work, one extra configuration option will not make an impact, and it would certainly be worth the increased default security. Such people can simply override the session.save_path value, and if they do that, we can turn this additional feature off (knowing that they know what they're doing). This will secure the default configuration and yet make things work for people who want to use sessions over several domains. We can make this on by default but also allow it to be turned off it case it creates problems for someone. -- Ivan Ristic, [EMAIL PROTECTED] [ Weblog on PHP, Software development, Intranets, and Knowledge Management: http://www.webkreator.com ] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [PROPOSAL] defense against session takeovers
This will secure the default configuration and yet make things work for people who want to use sessions over several domains. But I admit that this improvement can be seen as meaningless since any user on a shared server can write a script to list all sessions in a directory and then read all files. This can be cured only by using the proper PHP engine configuration. Therefore, let us document this and leave it as is. -- Ivan Ristic, [EMAIL PROTECTED] [ Weblog on PHP, Software development, Intranets, and Knowledge Management: http://www.webkreator.com ] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [PROPOSAL] defense against session takeovers
The general philosophy of PHP has always been to make PHP easy for the beginner yet flexible enough for advanced users. This fits that rule. Give the advanced users the tools to configure PHP to have per-virtualhost session handling, while sessions still work for the guy who just installed PHP on his own little server and really doesn't know what he is doing. That is fine for a philosophy. I would still like to try to make the default setup more secure. I agree, the least we can do is to document this. How about that we use the SERVER_NAME environment variable when generating session filenames? Instead of name like sess_, the name could be sess__, where is a server fingerprint? I understand that this is not foolproof (say, for applications that run on the same domain name) but it will solve the most serious cases (shared hosting solutions). -- Ivan Ristic, [EMAIL PROTECTED] [ Weblog on PHP, Software development, Intranets, and Knowledge Management: http://www.webkreator.com ] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: Re[2]: [PHP-DEV] [PROPOSAL] defense against session takeovers
Why would you switch on safe_mode if you have a dedicated server? That makes no sense. It can be useful to minimise the damage in case someone finds a hole in your PHP scripts, and the hole allows them to access files on the server. -- Ivan Ristic, [EMAIL PROTECTED] [ Weblog on PHP, Software development, Intranets, and Knowledge Management: http://www.webkreator.com ] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
