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...
Re:Dependencies
acme on 2002-08-15T08:31:40
I really dislike ExtUtils::AutoInstall. I also hate interactive installs. It has bugs (it went into an infinite loop for me yesterday - charming). I'd much prefer the distribution to do the proper CPAN thing and use MakeMaker so that CPAN or CPANPLUS (or my gentoo cpan ebuilder) can find out the dependencies easily and cope with it. Does anyone actually not use CPAN/CPANPLUS thesedays?Re:Dependencies
Matts on 2002-08-15T08:59:43
Sadly, yes. Lots of people who are new to perl don't even know about CPAN.
ExtUtils::AutoInstall is supposed to do the right thing when running under CPAN - it simply sets PREREQ_PM when it detects that it's running there. Also you can tell a module that uses ExtUtils::AutoInstall to be non-interactive via command line switches.
The infinite loop thing is bad. Hopefully you reported a bug;-) Re:Dependencies
james on 2002-08-15T08:48:23
TBH I'm quite happy shipping with low dependencies and low functionality. One of the points we've always tried to stress is that OpenFrame doesn't force you down a certain path, and it feels more like we're meeting that design goal with completedness-at-shipping with this sort of layout.
I can understand that its nice to be able to install something out-of-the-box and have it all work 100% but in reality I'm not sure that you're ever going to get that with a OpenFrame -- its not what it tries to be at all.
Still, its worth thinking about though...
