[Openinteract-dev] OpenInteract Mark II, a freeform jazz trio... [long]

[Chris W. <ch...@cw...>]

(Playing at an amusement park near you...)

But seriously. As some of you might know, I've been working the last
five or six weeks on the next big version (OI2) of OpenInteract. It is
not yet at a usable state, but it's getting there and has reached the
point where some basic structures have already gelled into code and many
of the new features are on their way.

This is not a full rewrite. Some of the current things about
OpenInteract will be unchanged. But many of the fundamental structures
are being heavily refactored. Yes, this will require code changes. No, I
don't know the extent yet. Much of the changes will likely be automated
(if you wish), and most of the rest you should be able to use a
cookbook. I am trying to keep backward compatibility, but I'm also
trying to do things the right way :-)

So what are the changes?

 - OI will run under other environments: CGI, standalone HTTP server
(which I hope to include with the distribution ala OpenFrame), and
others. This has been a big motivation for many of the changes.

 - There will be no longer be a base installation directory, just a
website directory. This simplifies a number of plumbing tasks. This also
means the development process will be far more streamlined. Instead of: 

  develop->export->install->upgrade->restart server

you will just need to do the normal webdev:

  develop->restart server

You can then do an 'export' when you reach a good milestone.

 - Much of the functionality in the ubiquitious $R has been split out to
three separate objects:

    * Context: server-wide info, current request/response

    * Request: current request (session, URL, cookies, authentication,
etc.)

    * Response: current response (content type, content, cookies, etc.)

 - All of the management tasks are moved out of the monster script
'oi_manage' and into separate subclasses of 'OpenInteract::Manage',
which defines a simple interface for tasks that manage websites and
packages. This also means that we can create a web interface for this
stuff if we like.

 - (This part is still a little fuzzy) Handlers will all be subclasses
of an OpenInteract::Action, which does all the dispatching, security
checking, content caching, etc. If a handler wishes to use security, it
will just set it as part of its metadata (in conf/action.perl) rather
than in the class itself. 

Other components (boxes, complex template widgets, etc.) will be actions
as well, so it will be extremely easy to lookup a resource and generate
content from it and have all the other stuff (security checking,
caching) just happen for you.

There are more changes and many more details, but I don't want them to
get lost in a huge email. Hopefully as this stuff gels into code I'll be
able to create manual pages along the way (similar to SPOPS::Manual) and
have these available for everyone to read.

I haven't yet put the code into CVS on Sourceforge because I didn't know
if anyone other than me would find it useful yet -- only individual
pieces of it are currently working. LMK if you'd find it
useful/interesting.

For timeframe: I hope to get this (and more), plus SPOPS 1.0 (Ray Z's
modified relationship specs and the inheritable stuff, finally) all done
and ready to kick butt by the Perl Conference in July. I'm going to be
submitting proposals for one or two talks, so hopefully I'll be able to
go this year.

Later,

Chris

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.