There's one thing I was wondering about: why would you actually want to use the DOM/XML writing functions of PHP to generate XML? I mean: we've been generating HTML without specific functions for over 10 years, so why would we need a library to build a DOM tree instead of outputting XML directly??
Well... I got an answer at PHP Forum: it makes sure your XML is well formed when you spit it out!
Ha! I could have thought about that!
Now I'm wondering if I should be using this as a replacement for echo in order to make sure I generate well formed XHTML all the time... ;) I mean... generating a DOM tree would be overkill, but generating the XHTML code on the fly with XMLwriter might actually work out pretty well...
Here are a few bits of information I collected at PHP Forum (Nov 9 & 10, 2005):
- It is estimated than no more than 5% of the servers running PHP have switched to PHP 5 yet
- PHP 5.0 is a feature release, not a performance release. Therefore it is slower than PHP 4.x. Therefore it makes no sense running apps designed for PHP 4 on PHP 5.0.
- PHP 5.1 should almost match the performance of PHP 4.4
- Rasmus will probably migrate Yahoo's servers from PHP 4 to PHP 5 once PHP 5.1 has undergone a few weeks without any major issue.
- It is extremely painful for everyone to make code that works on PHP 5 as well as PHP 4, especially because you cannot redefine the
clonestatement in PHP 4 for compatibility.
Okay, that's all I can recall right now! :P
At PHP Forum, Rasmus said this about the "templating engine question coming back every year":
PHP *is* a templating engine by itself. Adding another templating engine on top of it just doesn't make sense. The only situation where it makes sense, is when you don't trust the template to contain nice behaving code.
I so much agree...
Of course, in b2evo, you can't always trust the template/skin... so we'll need to implement some kind of templating... but we're really gonna make it lightweight!
The PHP Core Team is meeting this week to decide wether or not there should be some caching built into the next major release of PHP. (I guess that would be PHP 6).
I definitely hope the answer will be YES since this has been available on others platforms for ages (J2EE, ColdFusion, ASP...) and it's really missing when you want your app/site/service to scale to large numbers of users.
Furthermore, once they decide to include caching, they still have to decide which cache technology they'll build in.
There are many add-ons/plugins to PHP which do caching, but it's important to keep in mind that there are actually 3 different kinds of caching involved here:
- Caching the .php files in memory, so you don't access the disk everytime you include _header.php!
- Caching the compiled opcode for those files, so you don't have to recompile them all at *each* request!
- Caching arbitrary data from inside the script, so you can reuse it on subsequent requests without recomputing everything
There is one PECL extension that manages all of these 3 caching forms: APC. (Note: precompiled for Windows here). I'll bet on that one! Not only because I think it's doing the job as it should be done (easy setup, clean function syntax and everything), but also because Rasmus is already involved on that one's development team! ;)
Anyway, I think it's really important for PHP to standardize on some caching mecanism so we can design our applications to take advantage of it, no matter what host you'll be running it on.
The main reason we don't yet use shared memory data caching in b2evolution, is precisely because there is no standard that will be broadly available on hosts. Of course, we could still have included our own PHP class writing cache files, but that's bound to be less efficient than shared memory caching!
Edit: the big 'no' argument to including caching would be that because APC uses shared memory, it kind of breaks PHP's "shared nothing" architecture. With shared memory it is so much more likely that a small error will corrupt something that might eventually cause a larger crash... So, be bottom line is that introducing a shred memory architecture introduces a potential weakness, do we want that?
I've spent the last two days at PHP Forum Paris 2005. Very interesting stuff! I'll try to blog the most important facts (IMHO) over the week-end...
But, now when you think about it, I've been there last year also... Very interesting stuff also... And I still haven't blogged a line about it!
But it doesn't matter, I still have my notes from last year... they happen to be in the same notepad as those from this year! Guess I haven't used much paper for the last year... :P