Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

james (1129)

james
  (email not shown publicly)
http://whoot.org/

...

Journal of james (1129)

Wednesday August 14, 2002
11:57 AM

So whats new?

[ #7092 ]

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...

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Dependencies (Score:3, Interesting)

    by Matts (1087) on 2002.08.14 14:18 (#11758) Journal
    We went through a similar thing with AxKit and dependencies.

    I've come full circle with it in a way - at first I just shipped everything - and I think that made things easier for a while. Now in AxKit 1.6 everything got ripped out - it's a bad thing to ship with all the dependencies.

    So for CVS, I'm using ExtUtils::AutoInstall. It's a bit wierd, and certainly has bugs, but I think overall it's probably the best option - does the right thing if you're running under CPAN.pm, otherwise tries to download the modules separately.

    Anyway, maybe you should check it out.
    • Re:Dependencies (Score:3, Interesting)

      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?
      • 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 ;-)
    • 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.