Hello Stanislav, Monday, March 3, 2008, 7:59:41 PM, you wrote:
> Hi! >> 1) If mmap is supported, then use it >> 2) If mmap is not supported or does not work then read the whole stream >> 3) If that is not possible read char by char > Why should it read the whole stream into memory? The file could be very > big, maybe it would make more sense to read it is some chunks? > BTW, I see there are some substantial changes in streams there - new > file type ZEND_HANDLE_MAPPED, new "fsizer" handler. Will they be > dsecribed somewhere so other places which deal with streams could be > updated if there's need? Does it have any implication on extensions etc. > or it's isolated? The streams stuff is meant to integrate with the PHP streams layer which we take care of. In the beginning we thought we could live with the old interface but that wasn't really a good idea. So I came up with a new interface and all that this would break is stuff like Phar (well there is as far as i know nothing else like it) and guess I'll take care of it. Actually pohar already works nearly 100%. And since Phar is a moving target right now I wouldn't worry too much about it. Also if an application decides to do less than it can provide less handlers than it had to earlier. And well I could document stuff. But since when is that the PHP way? In fact when I document stuff inside the engine I tend to get strange reactions. >>> party library in PHP 5 core. Of course, PHP 6 has this dependency, but >>> we might want to not have such things in 5.x so that you won't have to >>> change your system too much while staying on 5.x. >> >> Are you saying we cannot depend on ICU in PHP 6 and have to redo it >> completely or what? > Just curious who you were answering to... Anyway, to be clear: > 1. PHP 6 is major version with its major feature being Unicode support. > 2. PHP 5.x is same-major branch, where you are not expected to have to > change your system in order to upgrade. Oh since when? Where did you read that? > 3. We do not expect people to take PHP 6 and have absolutely everything > work instantly from PHP 5. We try to minimize upgrade path, but major > version upgrades can take some adjustments. > 4. We expect people to upgrade from 5.2.x to 5.3.x without changing > their systems. Since when? And when did we ever say anything like that? Since when do we tell people anything about their system? > Is it clearer why I think PHP 5.x and 6 are different and why I think > ICU dependency in the 5.3 core might be a problem? I don't care at all. So far the plan was to bring in ICU and there is no need to start a new discussion here. All I said is that we might be able to do things better. But maybe taht is the complete wrong approach and I am all wrong. >> I Know there is some work left but when we do not apply the work now then >> we basically have two engines. In that case I'll just rewrite the engine >> completely and replace it. > I think better to have two engines one of which we can release than have > no release-able engine at all. Again, if you say you are 100% sure that > can be figured out quickly and not delay 5.3 release cycle to Q2 or Q3 - > great, let's do it. In software there is nothing like 100% Or is everything you work on bug free? Mine isn't. It took me more than two years to make re2c ready for this task (take this in whatever way you feel). > Since we were not going to have any major changes in > the engine until 5.3 is out anyway - the gap between your code and CVS > code won't be substantial. You could use a branch to make it even easier. How so? We don't use git or any other CMS that allows merging at all. I would love to switch to GIT or Subversion but I don't think this is reasonable given our development group/cycles. > As for rewriting the engine - I think that would be just a waste of effort. Good, then let's not do that :-) Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
