Also, PHP really needs something like Plack/PSGI/Rack so that you don't have to manually reconfigure the web server for every library you want to use.

The Apache configuration mentioned in this article is pretty generic.

PHP has a standard HTTP interface, unlike the other languages before WSGI/Rack/JSGI/PSGI came around. Of course, PHP's interface isn't function-based, so you don't have the advantages of stackable middleware.

A spec closer to the *SGI's would indeed be nice.

http://github.com/dhotson/kelpie

It actually works pretty well, no apache required! It's pretty fast too.. all the init stuff you normally have to do every single request can be done once on server startup.

I also wrote a little sinatra style framework to go on top of it: http://github.com/dhotson/kelpie/blob/master/demoapp.php

Anyway, it's turning out to be a pretty fun little project. :-)

When I've tried to write long-running applications in PHP I always get memory leaks. How do you handle this in Kelpie?

Yeah, it's probably going to have memory leak issues. It's pretty much inevitable unfortunately. I've thought about having the server monitor the memory usage and periodically respawn processes. I believe apache uses a similar technique.

I'm open to ideas on this issue though. :-)

It basically sets all the usual superglobals like $_SERVER, $_GET etc. Doesn't handle sessions just yet; I'm still working on that..

This is an interesting idea, but I like better my syntax though. But again, I'm not even a real programmer.

   I'm a poor self-promoter.
   <snip> 
   But again, I'm not even a real programmer.

  if (get('hello')){
    // do stuff
  }

Too bad mine grew to become a monster, pretty much like all other popular PHP frameworks out there. I guess simplicity really is one of the hardest features to implement.

with gpl v2, it was a requirement. hence gpl v2 licensed applications such as wordpress and drupal don't need to be shared with site users

code built upon the framework is derivation and thus, has to be licensed accordingly

    "To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying."

"Any of the license terms and conditions can be waived if you get permission from the copyright holder."

MVC is a descriptive point of view, not a prescriptive implementation plan. It's one of the only software idioms that's actually an Alexanderian Pattern, unlike the vast majority of the GoF that's just reflective of language warts/features.

There are tons of completely different ways you could describe the web as MVC:

  Model         View        Controller
  URL           Response    Request
  DB            Response    Request
  Response      Hypermedia  Sub-Requests
  LocalStorage  DOM         Javascript
  data://       JavaScript  DOM Events
  ...

BTW I don't want to start a flame war about MVC. I just got some question marks about using a PHP 'MVC' framework.

Were it not for that I would be in complete agreement with you; I have absolutely no time for any framework that does not allow you to construct a mock request object, throw it into the controller, and verify correctness of the response object produced.

For instance, events between M and V are pretty much required if you're doing it the "old way," but people tend to ignore that and just explicitly route messages through the C. The expression carries a lot less meaning now than it used to.