So whats new in OpenFrame 3.00? Quite a lot really. I'll start with the less important things.
One of the biggest complaints we got with OpenFrame was the sheer number of dependencies it has. We excused that quite reasonably I thought with the truth: we reused what we could. However, no matter how many times we explained ourselves, the question would still come up.
To escape that problem, OpenFrame 3.00 has been completely split up into seperate packages -- for example, the core package I released today has only the barebones of an OpenFrame server. There is no bundled apache integration, no bundled application mechanism, there is no bundled session management. However, I also released OpenFrame-AppKit, which has a lot of those things in it. Over the next couple of weeks I'll get the OpenFrame-ApacheKit out of the door, and you'll be able to stick OpenFrame into an Apache server again.
The single most important change is that everything is now a pipeline segment. In OpenFrame 2.00 when a request came in, we turned it into an OpenFrame::Request object, and then placed that in the pipeline for processing. With OpenFrame 3.00, we take the pipelining concept one step further, and the request will be placed in the pipeline, with the assumption that something in the Pipeline will turn it into an OpenFrame request object. OpenFrame now piggybacks off of the Pipeline module, so Pipeline segments should be usable elsewhere (for example, I have an evil idea in my head about PerlIO layers and the Pipeline module).
The other benefit for using the Pipeline module is that segments are instantiated objects, rather than classes, which makes everything faster, because there is no nasty collection of evals in the middle of the request processing.
This all means that OpenFrame is not backwardly compatible, but quite frankly, I'm happier that way. We've had to do a lot of work with OpenFrame at Fotango over the last year, and it has been a very useful exercise in pointing out the difficiencies of OpenFrame 2.
I'm pretty happy with the code now. It feels a lot cleaner to write for, and some of the inconcistancies have gone away (for example, in OpenFrame 2, slots and applications were not the same, but they felt very similar indeed, which led to much confusion).
Now its time to start porting internal stuff to it...