Programatically generating XML

If you have to generate XML, it’s usually considered good style to use one of these defined APIs like DOM or XMLWriter.

Just writing out a string to the line is considered bad practice because… why, actually?

Jeff Atwood once more wrote down what I have been thinking for quite some time now.

In many cases, just dumping out XML with sprintf or whatever your language provides you with is faster, independent of bugs in the libraries you use and easier to read.

There are five characters that need to be treated with caution in XML: the &, the <, the >, the " and the '.

Quoting even is straight forward and you usually don’t run into niceties like quoting backslashes in regular expressions you are passing to perl -e inside a double quoted string on your shell (I don’t even want to count the ‘s needed to actually get the regex parser in perl to see just one of them).

And even if you screw up, you can still rely on the XML parser to bail out if something is wrong.

The time you waste learning your library, coping with its bugs and finally working with the usual bloat of todays OOP interfaces (interface as in “user interface”) far outweighs the occasional quoting problem which should not happen anyways.

And don’t make me get started on trying to understand the structure of the XML code like Jeff posted is going to create:

System.Text.StringBuilder sb = new System.Text.StringBuilder();

XmlWriterSettings xs = new XmlWriterSettings();
xs.ConformanceLevel = ConformanceLevel.Fragment;
xs.Indent = true;

XmlWriter xw = XmlWriter.Create(sb, xs);
xw.WriteStartElement("status");
xw.WriteAttributeString("code", "1");
xw.WriteEndElement();
xw.WriteStartElement("data");
xw.WriteStartElement("usergroup");
xw.WriteAttributeString("id", "usr");
xw.WriteEndElement();
xw.WriteEndElement();
xw.Flush();
return sb.ToString();

If you are seeing this in code you have to maintain (but you have not written), how would you tell what XML it generates? How does the readability of that compare to this?

string s =
@"<status code=""{0}"" />
<data>
<usergroup id=""{1}"" />
</data>";
return String.Format(s, "1", "usr");

Note that I’m not that much of a .NET guy, but I’m quoting Jeff’s code here

Summary in one word: Jeff’s Article: ACK!

PHP Stream Filters

You know what I want? I want to append one of those nice and shiny PHP stream filters to the output stream.

I have this nice windows-application that recives a lot of XML-data that can be compressed with a very high compression factor. And as the windows application is for people with very limited bandwith, this seems to be the perfect thing to do.

You know, I CAN compress all my output already. By doing something like this:

<?php
ob_start();
echo "stuff";
$c = ob_get_clean();
echo bzcompress($c);
?>

The problem with this approach is that the data is only sent to the client once it’s assembled completely. bzip2 on the other hand is a stream compressor that is very well able to compress a stream of data and send it out as soon as a chunk is ready.

The windows client on the reciving end is certainly capable of doing that. As soon as bytes come in, it decompresses it chunk-wise and feeds it to a Expat based parser which will handle the extracted data. Now I want this to happen on the sending side aswell.

The following code does work sometimes:

<?php
  $fh = fopen('php://stdout', 'w');
  stream_filter_append($fh, 'bzip2.compress', STREAM_FILTER_WRITE, $param);
  fwrite($fh, "Stuff");
  fclose($fh);
?>

But sometimes it doesn’t and produces a incomplete bzip2-stream.

I have a certain idea of why this is happening (no sending out of data to the filter on shutdown), but I can’t prevent it. Sometimes the data is not put out which makes this method unusable.

I’m afraid to report this to bugs.php.net as I’m sure it’s something PHP was not designed for and it’ll get marked as BOGUS faster than I can spell ‘gnegg’.

So this means that the windows-client just has to wait for the data being extracted, converted to xml and compressed.

*sigh*

(thinking of it, there may be this option of outputting data to a temp-file (to which handle a filter is assigned to) and the read it out to the browser immediately afterwards. But come on, this can’t be the solution, can it?)

Update: I’ve since tracked the problem to a bug in PHP itself for which I found a fix. My assumption of writing to a temporary file could help was wrong as PHP itself does not check the return value of a bzlib function correctly and never writes out a half-full buffer on stream close. Neither to the output stream nor to a file.

Flattening Arrow Code

In an equally named article, the excellent (yes. Really. This is one of the blogs you HAVE to subscribe to) Coding Horror blog talks about flattening out deeply stacked IF-clauses in your code.

I so agree with the guy, though there seem to be two opinions in the matter of the points 1 and 4 in the list the article provides:

Replace conditions with guard clauses. This code..

Many people disagree. Sometimes because they say that Exceptions are a bad thing (I don’t get that either) and sometimes because they says that a function should only have one return point

Always opportunistically return as soon as possible from the function. Once your work is done, get the heck out of there! This isn’t always possible — you might have resources you need to clean up. But whatever you do, you have to abandon the ill-conceived idea that there should only be one exit point at the bottom of the function.

I once had to work with code a intern has written for us. It was exactly written as Coding Horror tells you not to. It was PHP code and all of it basically took place in a biiig else-clause around the whole page, with a structure like this:

if (!$authenticated){
   die('not authenticated');
else{
  // 1000 more lines of code, equally structured
}

This is a pain to read, understand and modify.

To read because the thing get’s incrediby wide requiring you to scroll horizontally, to understand because you sometimes find an }else{ not having the slightest idea where it belongs to, requiring you to scroll upwards for half a file to see the condition and to modify because PHP’s parser is inherently bad at reporting the exact position missing or spurious braces, which is bound to happen when you extend the beast.

But back to the quote: I talked to that intern about his code style (there were other things) and he mostly agreed, but he refused to change those deeply stacked IF’s. “A function must only have one single point of return. Everything else is bad design“, he told me.

Point is. I kinda agree. Multiple exit points can make it hard to understand the workings of a function. But if it’s a single, well definded condition that makes the function unable to continue or if the function somehow gets its result way early (like if it’s able to read the data from a cache of some kind), IMHO there’s nothing wrong with just stopping to work. That’s easy to read and understand and certianly does not have above problems.

And of course every function should be short enough to fit on one screen, so scrolling is never neccessary and it’s always obvious where that }else{ belongs to – at least without making you scroll.

Personally, I write code exactly as it is suggested in that article. And I try to keep my functions short. Like this, it’s very easy to understand the code (most of the time) and thus to extend it. Even by third parties.

Christoph, do you agree? And: No, I’m not talking about that sort-by-material-group-thing. That IS unclean. I know that (and so do you now *evilgrin*)

Strangest JavaScript error ever

Let’s say you create some very nice AJAX-stuff for a web project of yours. With nice I mean: Not breaking the back-button where its functionality is needed, not doing something that works better without AJAX, and doing it while providing lots of useful visual feedback.

Let’s further assume that the thing works like a charm in every browser out there (not counting Netscape 4.x and IE in all versions – those are no browsers).

And then, IE throws this at you:

Unknown Runtime Error

Needless to say that the HTML output in question had a line count not even close to 370, so finding this thing easily was out of the question.

The solution: IE is unable to write to innerHTML of a TBODY element. But instead of providing an useful error message or even a link to the source with the line in question already highlighted (that’s what Firefox would do), it just bails out with completely useless error information.

*sigh*

(btw: That mix of fonts in the details section of the error message is just another indication of IEs great code quality)

The myth of XCOPY deployment

Since the advent of .NET, everyone is talking about XCOPY deployment.

XCOPY deployment means that the applications are distributabe without a setup routine. Just copy the file(s) where you want them and that’s it.

We are being told that this is much easier and safer than the previous non-.NET approaches which – as they continue – always required a setup program.

The problem with those statements is that they are all false.

First the ease of use: Think of it: Say you want to install Cropper (which made me write this entry. I found that screenshot utility via flow|state). What you are getting is a ZIP-File, containing 5 files and a folder (containing another 6 files). Nearly all the files are needed for the application to run.

XCOPY deployment in this case means: Create a folder somewhere (Windows guidelines advocate you create that in c:Program Files which is a folder windows does not want you to mess with and per default does not display its contents) and copy over all those files, being aware not to forget a file or the folder in the archive.

But it does not end there: As you have to launch the application and going all the way through those folders, you will want to have a shortcut in the start menu or on the desktop. With this new and “better” method of deployment, you’ll have to do that yourself.

This is a tedious task involving lots of clicks and browsing. An unexperienced user may not be able to do this at all.

What an unexperienced user will want to do is to copy that application right to the desktop. But in this case this does not work well as the whole application consits of multiple interdependant parts. Copying only the .EXE will break the thing.

Compare this with Mac OS X

In Mac OS X, application also consist of multiple parts. But the shell is built with XCOPY deployment (not called like this, of course. As a matter of fact, it does not have a name at all) in mind: In OS X, you can create a special kind of folder which is a folder only on the file system. The shell displays it to the user as a single file – the application.

Whenever you move that “file” around, OS X will move the whole folder. When you double click the “file”, the application will launch (the binary is a file somewhere in this special folder. The shell is intelligent enough to find and launch that). When you delete it, the shell will delete the folder including it’s contents (of course).

This makes XCOPY deployment possible as the applications become one piece. You want it on the desktop? Drag it there. In the Application folder (without warnings about not being allowed to mess with its contents, btw)? Drag it there? On an USB-Stick? Drag it there.

Well. There’s one other thing: It’s the users data and the applications data. Most of the applications will be used to create data with them. And all application somehow create their own data (for saving things like the window state or position for example). As all modern OSes are multiuser ones where a user does not necessarily have to have write access everywhere, there’s the concept of the home directory. That one is yours. You may store whatever you want in there.

So naturally, this is the place where the applications should store data to0.

User data goes to a specific folder of the users choice. Per default, applications should suggest some Documents-Folder. Like “My Documents” in Windows or “Documents” in Mac OS. In most of the cases you don’t want to delete that on uninstall.

Application settings are in Windows stored in the Registry (under HKEY_CURRENT_USER – a hive that belongs to the current user like his home folder does. And actually, the file behind that is stored in the home folder aswell (USER.DAT)) or in the Application Data folder below the users home folder.

Mac OS X Applications are advised to use the Preferences-Folder inside the Library Folder inside the users home directory<./p>

Now. Application data is something you want to remove when you uninstall the application (which means deleting a bunch of files in Windows or one “File” in Mac OS). Application data is created by the application, for the application. No need to keep that.

In Mac OS, you can do that by going into the folder I’ve described above and delete the files – mostly named after your application. There are no warnings, no questions, no nothing. Just delete.

In Windows, editing the registry is off-limits for end-users and very, very tedious to do for experienced users (due to the suboptimal interface of regedit and because the whole thing is just too large to navigate it easily), so you generally let the stuff stick there. Deleting the Application Data in the same-named folder is also impossible for the end user: That folder is hidden by default. Explorer does not display it. And it’s hard as hell to find, as you have to manually navigate into your home directory – there’s not easy GUI-access to that. So that sticks too.

All in all, this means that windows is – at least in its current state – very unsuited for XCOPY deployment:

  • It does not help at keeping together things that must be together
  • Its complex file system structure makes it hard to copy the application where windows wants it to be
  • Manually creating shortcuts is not feasible for an unexperienced user
  • Uninstallation of Application Data is impossible

So, we found out that XCOPY deployment is not easy at all. Now let’s find out how it’s not true that only .NET enabled you to do this.

Ever since there is Delphi, there theoretically is XCOPY deployment.

Delphi is very good at creating self-contained executables.

With delphi it’s a breeze to create one single .EXE containing all the functionality you need. That one single .EXE can be moved around as a whole (obviously), can be deleted, can even be put right into the start menu (if you want that). It can even create the start menu shourcuts, delete application data – basically configure and clean itself

It can even uninstall itself (embed an uninstaller, launch that with CreateProcess and set the flag to delete the .exe after it ran). And it can contain all it’s image and video and sound data it needs.

Just because nobody did it does not mean it was not possible.

Face it: Windows users are used to fancy installers. Windows users are not at all used to dragging and dropping an application somewhere. And currently Windows users are not even able to do so as dragging and dropping will break the application.

OS X and now Linux allow for true XCOPY deployment of desktop applications.

Well, you say… then maybe XCOPY deployment is just for those fancy ASP.NET web applications?

Maybe. But after XCOPY you need to configure your webserver – at least create a virtual directory or host. A good installer could do that for you – if you want it to.

Microsoft too has seen that this XCOPY thingie is not as great as everyone expected, so they added the new “One-Click Install” technology, which is not much more than a brushed-up MSI file which does a old-fashioned install.

To really make XCOPY deployment a reality (btw, I’m a big fan of depolying software like this), there must be some changes within Windows itself. Microsoft, copy that application bundle feature from OSX. That one works really, really good.

Btw: Am I the only one that thinks “XCOPY deployment” is a very bad term? What is XCOPY? Who the hell still uses XCOPY these days? And when we are using the command line: COPY would be enough.

On the search of a text editor

When I began with this blog, I was using jEdit because of its wonderful list of countless features directly optimized for the programmers needs.

It was lacking one thing though: PHP support. While it provides (excellent) syntax highlighting, there’s nothing more. No code completition, no parameter hints, no code browser. While many people tick those things off as useful but not needed, I tend to disagree:

Sometime around autumn 2003, I gave the Zend Studio another try. And it has matured quite a lot since its first release. The speed problems were fixed, some editing features came back… nice.

What made me stick to Zend Studio is the above features: Code completition and parameter hints.

I know that you can just look the order of a functions parameter up in either your (or someone elses) code or in the manual, but it always interrupts your work. Not only that, you have to actually know where to look. Is it in the PHP manual? In code file a? In file b? Maybe in some library installed in /usr/lib/php (PEAR)? Zend Studio provides me with the parameter hints regardless of where the file is stored – provided it can read them.

This is a killer-feature. It immensely increases ones productivity. Whatever editor I’m ever going to use: It must have parameter-hinting for PHP. And it has to work as good as it does in the Zend IDE.

The Zend IDE has other problems though. What it has in parameter hinting, it lacks in basic editing features. Remove whitespace at the end of lines? Comment out a block? Smart autoindent (another thing where jEdit shines)? Splitting the editing window? No. Neither of them.

What pisses me off most (besides the whitespace problem as that creates very ugly SVN commits) is the font renedering though. Now that I finally found a font I really like, I’m unable to use it in the mostly used editor environement. Like many other Java applications Zend Studio does not support cleartype. And if you hack around a bit to run ZDE in a Java 1.6 alpha, the whole application will use cleartype – the whole application except the editing window, of course. Consolas looks really bad without ClearType.

Actually, any of the fonts I do like for programming (basically any besides Courier New) looks bad without ClearType, which means that I’m programming PHP with Courier as my font.

PHP of course is my main language at this time, so I’m doing most of my work in an environement that is not to my liking at all.

So… time for a new editor. Here’s what I’ve tried:

  • jEdit again. Now has a PHP parser plugin, which is completely unusable unfortunately: It parses while you are typing and as soon as it detects a syntax error (which is bound to happen while you are writing a line), it puts the keyboard focus to the error list(!!!!). This means that I have to type like this: function gnegg([TAB]$param1,[TAB]$param2){[TAB], the [TAB] meaning me hitting tab to get the focus back to where it belongs. Additionally, there’s no parameter hint, which is a must for me. As much as I’d like to use jEdit. It’s not possible like this. Sorry. (even though jEdit actually renders Consolas quite right with its own implementation of subpixel hinting).
  • PHPEclipse: An Eclipse plugin (even though Eclipse is written in Java, it uses SWT and thus the native font rendering of the underlying platform, meaning that cleartype is usable) teaching the JAVA IDE how to do PHP. Unfortunately, many of the great features in eclipse are part of the JDT plugin suite, so every language has to redo the stuff in there. PHPEclipse is seriously lacking in the features departement and the parameter completition is missing aswell.
  • UEStudio. Well… let’s try it with a commercial offering. UEStudio is a enhanced version of UltraEdit. They emphasize on their PHP support. You guessed right: No parameter hints.
  • phpEd, Maguma Studio, … I did not even try them again. My last experience was very, very painful. While Delphi is a RAD tool allowing to make quick progress, you have to be as careful with memory allocation as in every other native-compiled language. None of those Windows-Only-PHP-Editors seem to care about that, so they crash all the time. No alternative.

Well… that’s it for now. Please. Anyone! What are you working with? Is there a editor with the editing features of jEdit, the font rendering of eclipse and the PHP-specific features of Zend Studio (auto completition and parameter hinting)? I don’t need no profiler. No debugger. Just a good editor.

Am I doomed to write PHP with Courier New for the rest of my life?

Nice font…

I have my windows set up with ClearType™ enabled. Now, for Longhorn, they have created some new fonts, specially hinted for configurations with ClearType™ enabled. One of them – Consolas – has a fixed width and is for use in programming environements for exmple.

Sample Screenshot

I really like this font. It’s very easily readable but still looks great and smoothed.

Unfortunately, in environements without cleartype, it looks really crappy. One of those environements, unfortunately still is the Java Runtime and with this the Zend Studio. Actually, no single font i’ve tried in there looks acceptable. The best of them – still – is Courier New which is a real pain.

What I liked most about Consolas is also visible on the screenshot: Usually I’m working on a bright-on-dark editor scheme because it makes the thing a whole lot more readable for me. With consolas I don’t need this any more. The font looks good and readable even on a white background. This in turn takes away a lot of strain from my eyes.

Nice. I’ve copied it over from my Lonhorn VMware-Image to my default working-environement and I’m really, really happy

No topic-based help system installed

Recently I had to do some Delphi-work again. To my surprise, the online help seemed to have stopped working. I always got this error message:

No topic-based help system installed

Programming without an online help is very tedious and sometimes nearly impossible.

When I had to look up in which Unit TWinControl is declared, I had two possibilities: Either look it up in the source code (Borland ships the full source code to their class library) or fix the help system once and for all.

I deceided to do the latter (searching after TWinControl is no fun).

Googling in the web turned out nothing. In Groups most of the time, the suggestion was to reinstall the whole thing

I absolutely did not have time for this, so I dug deeper.

The problem is caused by the installation of the VS2005 Beta which resets some AppID-GUUID. Afterwards delphi crashes while loading the IDE-package htmlhelp290 which in the end causes delphi to think that there’s no help installed

I fixed it doing the following:

  1. Reset the help-viewer-appid. In the registry under HKEY_CLASSES_ROOTAppIDDExplore.exe, set AppId to {4A79114D-19E4-11d3-B86B-00C04F79F802}
  2. In HKEY_CURRENT_USERSoftwareBorlandBDS3.0Disabled IDE Packages remove the entry for htmlhelp290 that has been created.
  3. Start Delphi and use the help again

What I don’t know is if this has a negative effect to VS, but this does not matter for me: I need Delphi to work.

The whole thing is a consequence of the .NET orientation of delphi: Earlier, Delphi was as self-contained as the executables it can build: Drop it into a directory and run it. No problems, no questions asked.

With Delphi integrated into .NET and using .NET-Components, problems begin to rise: First there was a bug in D8 causing it to stop working after .NET 1.1 SP1, now this.

Hopefully, they find a way back to both .NET (for the acceptance in the buzzword-centered world where you can’t have a dev-tool not .NET capable) and self-containment.

Once more: PHP and SOAP

I can’t reist: I made my third attempt at getting a SOAP-Server in PHP to work (I only documented my first try here on the blog).

My first try was a little more than two years ago. That one failed miserably.

The next try was last november. I came somewhat further than I did my first time, but Visual Studio was unable to import the WSDL correctly as soon as I was passing arrays of structs around

And now I tried again – this time with PEAR SOAP 0.9.1

This time all looks so much better. First of all, I do this because I really have to: For one of our PopScan customers, we are accessing their IBM DB2 database – currently using a Perl-based server that’s nearing the end of its maintainability, so I deceided to redo it with PHP (PHP-code is somewhat cleaner than Perl code and I’m more fluent in PHP than in Perl)

The DB2-client (especially the one needed for that old 7.1 database) is clumsy, a bit unstable and really not something I want to link into our Apache-Server that serves all our clients.

So the idea was to compile another apache, run it on another port, bound to localhost only. Add PHP with the DB2-client. Access this combo via some way of RPC with the nice DB2-free standard-installation.

Well. And instead of once again designing a custom protocol (like I did for the Perl-Server), I though: Maybe give SOAP another shot.

In contrast to previous experience, this time, it was the Server that worked and the client that was failing. Using PEAR SOAP 0.9.1, creating the server (which creates the dreaded WSDL) went without flaw. This time I was even able to import the WSDL into VS 2003, which I tried just for fun.

Passing around arrays of structs of structs was no problem at all. After building the self::$__typedef and self::$__dispatch_map arrays, passing around those data types has become really intuitive: Just create arrays of arrays in PHP and return them. No problem.

Well done, PEAR team!

This time I’ve had problems with the PEAR SOAP Client. It insisted in passing around ints as strings which the server (correctly) did not like.

Instead of using lots and lots of time debugging that, I went the pragmatical way and used PHP5’s build in SoapClient functionality. No problems there.

And then it suddenly broke

My test-client was written for the CLI version of php which was version 5.0.4. The apache-module of the live-server was 5.0.3.

All I got with 5.0.3 was a HTTP Client Error (SoapFault exception: [HTTP] Client Error).

Whatever I did, it did not go away, but to my delight I have seen that PHP did not even connect to the server to fetch the WSDL. This was good as I was able to debug much quicker that way.

In the end it was the URL of the WSDL. Every version of PHP5 (even the 5.1 betas) – besides 5.0.4 – does not like this:

http://be.sen.work:5436/?wsdl

it prefers this

http://be.sen.work:5436/index.php?wsdl

I ask now: Why is that this way? The first version is a valid URL aswell. The served WSDL is correct – it’s the same file that gets called and it returns totally the same content. This is so strange.

After all, I have to say. SOAP with PHP – after two years – still is not ready for prime time. It’s still in the state of “sometimes working – sometimes not”. But as I now have an environement where it’s known to be working and as I’m in total control of said environement, I will go with SOAP none-the-less. It’s so much cleaner (and more secure: more people than just me are looking at the SOAP-code) than designing yet another protocol and server.

Oh. And the bottom line is: Never trust protocols that call themselves “simple” or “lightweight” ;-)

31337 OOP code?

In the current issue of php | architect, there’s an article about “enterprise ready” session management. While it provides a nice look about how to structure your application (besides the capital mistake of endorsing a multiple-entry application structure – but I’ll save that for another post) and about some design-patterns, I have one big objection to the article: It’s basically saying that the $_SESSION-things in PHP are not enterprise-ready. The article names three reasons:

  1. It is not OOP enough
  2. The Session-ID is guessable
  3. The storage location for the session-data does not work with load balancers

The article then goes fruther and writes a complete replacement for PHP’s session API

Now. Le’ts have a look those points:

Point 3 is valid. If you load balancer cannot guarantee that each subsequent request from a user goes to the same server, /tmp is not a good place to store session data. What the article does not tell you is that most load balancers actually do make that guarantee. Reading the session-data from a file, unserializing it, using it, serializing it, storing it to a file probably is faster than doing the same thing with a database. Maybe you should do some testing and then deceide – at least when you have the real enterprise-grade-load balancers at your disposal.

Point 2 is also somewhat true, but the workaround provided by the article is not any better than what PHP already does. I especially dislike taking a hash of the first two octets of the IP-adress for protection against session spoofing. Hey. 2 octets of IP-range are not checked. This are 65536 addresses. Say I want to spoof sessions on your site, instead of those 4 billions of users I only have 65 thousand to try it with, but let’s say even only 1% of the users in said range do some online financial transactions on your site, it’s worth it for me. I just make an accaount at a particular ISP and try out my range.

It’s unfair to say PHP’s session ID generation is weak because it uses the systems time (amongst other things) and then create a replacement algortihm using the systems time (amongst other things).

The idea with the second ID is somewhat valid, but does not protect at all against network-based attacks (listening on the network and sending a valid request)

My biggest concern – the one that actually made me write this – is point 1. Tell me: What’s better at

 HTTPRequest::getSession()->getValue('gnegg');

than

 $_SESSION['gnegg'];

As I see it, the first version has three distinct disadvantages:

  • Depending on the state of PHP’s optimizer, this involves two function calls (in PHP userland code – and maybe countless others in the backend) per variable you query (and with the proposed implementation one additional database query(!)). Function calls are expensive. This is inperformant. Not with two to three queries but with maybe 100 or 1000 per second
  • The second method is the one documented and endorsed by PHP. Any coder you will find will know what it means, and how to work with it. Whenever you hire a new coder, he immediately will understand your session management code and will be able to concentrate on the business logic. The first method does not have this advantage. It’s just another hurdle for the coder to take before being able to be productive. A needless hurdle
  • It’s more code. More to type. More work to do. Thus inefficient for your programmers.

Saying the first one is better because it’s more OOP is like saying “I am more 31337 than you because I’m using Windows”, or “rogues in world of warcraft are more 31337 than warriors” or … take your pick (a phrase involving vi and emacs springs to mind).

So. From the three points the author of the article had to present, only one, maybe two are valid. Does this justify dumping the whole session management functionality in PHP? No it does not. Dumping ready-to-use funcationality is always bad. Especially if the funtionality you want to dump is extendable (and thus fixable for your purpose).

The PHP session management can be customized! Just have a look at the manual. There is session.save_handler, session.serialize_handler. There’s even session.entropy_file

So after all, another of those people trying to be god-like by writing about the enterprise without really knowing what it means. The java world is full of such individuals. And now PHP is getting them too. The price for being known? Maybe.