One more good news for you, YAML-users. :) I’ve implemented emitter functionality in php-binding of syck library. It is quite straight-forward, no fancy stuff for now, but it should work :)

Supported datatypes:

• associative arrays

• indexed arrays

• strings

• integers

• floats

• booleans

• null

Objects are simply ignored now, though I am planning to add support for them later. See TODO for details.

Example, to give you idea:

$data = array(
  'items' => array(
    'item 1',
    'item 2'
  ),
  'count' => 2
);
echo syck_dump($data);

take a look at my previous yaml-post for installation instructions.

Let me know how this works for you :)

p.s. should I change the name of that function? :-/

Better late than never. I’ve released updated lighttpd packages for MacOS-X’s Fink. It is Lighttpd 1.4.15 this time. Also, I added memcached support to mod_cml and mod_trigger_b4_dl.

As usual, if you have any good or bad feedback — let me know :)

I have released mysql-query-builder 1.0.2. Still lacks formal documentation, but 100% covered by unit-tests which can be treated as such.

MySQL Query Builder is a set of PHP5 Classes which can… (surprise!) build correct MySQL5 queries for use with PDO’s prepare/execute. This things rocks really hard if you need to implement some kind of database layer (I implemented ActiveRecord this way) in your app and building queries in dynamics.

While working on my app-server code, I bumped into a need to parse (and produce) cookie-headers, so I went to look for some specs…

At first, there was Netscape and their first spec which wasn’t Y2K-compliant. Then, there was 1997 and the new spec: RFC2109 which fixed Y2K problem as well as couple of other minor issues — this is the specification which is used by the major part of browsers, these days.

Then, in the year of 2000 RFC2965, which brings some quite interesting stuff. Unfortunately, this one is not supported by any browsers but Opera. (one more bit in a pile named “Opera is the most innovative standards-compliant browser”)

mnot has a nice article about support of cookies standards by browsers.

Now, about server-side…

PHP supports RFC2109 enhanced version of the Netscape standard (as mentioned in comments) and (since 5.2) microsoft’s “http-only” extension. Python has support for 2965, but it is turned off by default. Ruby seems to support 2965, but I didn’t test it, neither found enough evidence

I wonder which way should I implement this… Should I try detecting client capabilities and send cookies in corresponding format (if there is ‘Cookie2: $Version=1’ header I use SetCookie2, else I use SetCookie)? Or should I leave the this decision to the user?

There was a comment by Olivier to one of my previous posts mentioning, that php was still leaking memory even on the simpliest example. That’s not exactly true. I added some more memory-information output to that example and made “hard” testing by ab. Here are some results:

Hello world! #22960
Memory usage: 232312
Peak Memory usage: 275352
Memory usage last growed at request#71

Looks good enogh for me :)

p.s. weekend is coming — I will be posting some more-interesting stuff

Thanks for all the comments to my “Application Server in PHP? well… Yes!” posting. I was really amazed to see that many interested people. Your support gives me a great motivation. Thanks, guys! :)

I am currently thinking about proper object hierarchy and, actually, I changed it completely 3 times already in my thoughts. I finally “see the light”â„¢ and will implement it on a weekend. I think about converting SCGI-part to a simple “driver” and move all http-related stuff to a separate driver-agnostic set of classes (Probably, that would be a class per kind of http-request and a class per kind of http-response). This way, I would be able to implement FastCGI as anther driver without altering applications. If you have any better ideas — let me know.

For now, I made another example application. This time, with some benchmarking in thoughts. Here it is.

This example supposes, that you have ezcomponents folder on the one level with the svn-checked-out “trunk” of my googlecode-project. And, you can start “runner.php” both as SCGI-server (using CLI) or as usual mod_php/(fast)cgi application. The idea was to see if there will be any noticeable speed difference between approaches. But… it showed the other thing :)

I used ezcGraph/classtrees_Graph.html) in my application and noticed a serious memory-leaking. Obviously, ezcGraph has the forementioned in comments problem with cycled references. The solution is, to add some kind of ”public function clean()” method, which would remove references in the object, and objects which were auto-generated by it, so it would later be cleaned-up by a garbage-collector. I implemented a quick-fix locally and it did help to some degreee, but I definitely missed some references, so it still leaked. I think that someone who knows internals of eZComponents better should do it.

Derick? Anyone? Can this be done?

Short story: I made the initial implementation of SCGI protocol in PHP. Check it out! :)

Long story: Some time ago I was ranting about PHP and it’s “way” of handling FastCGI. The idea is to have persistent PHP-application which would handle requests from inside. This would allow us have “real” persistent cache in application (persistent connection to arbitary resources, preparsed XSLT’s in memory) and reply to queries really fast as we wouldn’t need to load all the classes on each request (classes would be loaded only once, during app initialization). And no, APC and similiar technologies do not completely solve this problem.

I finally found some time (and inspiration) to do something in direction of implementing FastCGI the way I see it. Initially, I was going to implement FastCGI-functions in php-extension, but that would require more time than I currently have, so I started with a simplier task: I implemented SCGI protocol (which is way simplier than FastCGI) in pure php-code (which is easier, again, and let’s me change API faster, during development).

This thing already works and you can test it if you have SCGI-enabled server (apache and lighttpd will do) and PHP 5.2.1+ (cli). At first, you need to get latest sources from my google-code project. Sources come with an example.

Some comments to ease understanding:

• Start by including SCGI/autoload.php file — it will take care of including all SCGI-classes

• Create your class by extending SCGI_Application. It needs to have two methods: public function __construct and protected function requestHandler. Constructor should call parent::__construct optionally with the stream-url. By default, application will listen on tcp://127.0.0.1:9999.

• requestHandler is the function which is called by application on every request. This is the point where most of the things should happen. Request-data is available from $this->request() and Response-data should be given to $this->response(). See example for details

• To see some result you need to tell your web-server, where your application’s socket is. Example for Lighttpd is available in repository

Warning: This is the pre-pre-release. API will be changing.

UPDATE: Code of this project was moved to github: http://github.com/indeyets/appserver-in-php

Some internal feeling makes me believe, that Smalltalk would be an ideal language for Haiku-OS/OpenBeOS (which looks more and more alive, again).

BeOS was always about C++, opposing UNIX’es, MacOS’es and Windows’es choice of C (well, formally, windows had C++ api, but, still, it was very C-ish in it’s essence). Years passed, MacOS switched to Objective-C, Windows switched to C#. Both of these languages are higher-level OOP languages which have some kind of memory-management. C++, while it has some advantages, still is not as easy and dynamic as these languages are.

Unfortunately, both Objective-C and C# are developed by Apple and Microsoft (correspondingly) behind the closed-doors.

So, what is the alternative? I see two of them:

• D

• Smalltalk

D is good, as it makes a step from C++ to real life, but is still low-levelish, by design. memory management will solve some headaches, but programming in it won’t be as fun as it can be. I like to see D as a language for writing libraries.

Smalltalk, on the other hand, is a high-level dynamic language which is just what is needed. Once you “taste” the fruit of dynamic languages you wouldn’t want to code high-level tasks in static-languages anymore (static is extremely good in low-level, though). To give you a brief idea on what all this is about, there is a nice article by a game developer who switched from C++ to Smalltalk: Learning to Talk: Introduction to Talking.

Further reading:

• Comparison of Objective-C and Smalltalk

• Smalltalk implementations

• Ambrai Smalltalk (Smalltalk for MacOS-X)

• F-Script (Smalltalk-based scripting environment for Cocoa)

• Comparison of programming languages @ wikipedia

Alan Knowles writes a lot of interesting articles about D language. I still wait for some project to appear, which will give me a reason to do something in D.

It looks so damn elegant

One more addition to Fink from me: BOOST_FOREACH. This is one of my favorite extensions of C++. It lets one to iterate over virtually anything that can be iterated, while still being extremely effecient.

Here is a very nice introduction to Boost.Foreach.

(If you don’t know…) Fink is a project that brings the full world of Unix Open Source software to Mac OS X.