[MTOS-dev] Experimental Dispatcher

[Timothy Appnel]

Sorry I feel behind and I'm just catching up here.

On 2/3/08, Reed A. Cartwright <reed at scit.us> wrote:

> I'm not sure either, other than the fact that it makes supporting
> FastCGI, CGI, and mod_perl more centralized and easier to manage.  I
> think shifting MT::App over to CGI::Application falls in the category of
>   changes that help migrate MTOS from using homebrew solutions to using
> established libraries.  It'd probably help MTOS cutdown on memory leaks.

I'm not sure  CGI::App will specifically cut down on memory leaks.
Your dispatcher kind of sticks a band-aid on the real problem -- there
shouldn't be memory leaks.

IMHO, there are other more important reasons for migrating away from
homebrew solutions and to module in CPAN that exist beyond MTOS.

One is effectively leveraging resources. What does MT gain from having
its own application framework? (I can ask this same question of
JavaScript frameworks and some other things in MT.) How will that
differentiate MT from other tools? How does it improve the user
experience or get more people using the tool? It doesn't. Could the
engineering resources of Six Apart and this community be put to use on
other things where the questions are true or an alternate does not
exist? I'm pretty sure the answer to that is yes. So if there is a
passionate community of developers that have put a lot of time, effort
and field testing in to a library that provides essentially that same
functionality, I'm all for it so we can work on the things that really
need it.

Another is in better embracing open source. While my first point is
more operational, this one is more PR. Releasing MT under the GPL is a
good first step, but there is still a certain level of mistrust (I'm
not suggesting that its founded or not) nor are open source developers
knock down the MTOS doors to contribute. Drawing in developers from
other communities with some of the tools they are already familiar
with and using would IMHO contribute to generating more interest and
breaking done the walls that I believe many believe surround MT.
Conversely taking parts of MT that don't exist in the Perl/CPAN world
(the template engine, registry, Promise, FileMgr ) and breaking them
off as their own standalone library would have a similar effect in my
experience. Developers are more likely to write MT like apps that
borrow from how it works indirectly learning about MT and perhaps
contributing back to its development. Doing both of these clearly
demonstrate that Six Apart is serious about MT as open source software
and that there is something to gain by contributing.

> As far as CA-Dispatch, it has a really nice ability to dynamically load
> app modules.  No more coding of .cgi or .fcgi scripts to execute an app,
> having the .pm file is all you need.  It can also clean up our urls,
> e.g.: http://localhost/cgi-bin/mt/cms/edit/entry/2/1054/.

Yes, this is why I love that dispatch module. I also like the
"auto_rest" mode and the coding standard it promotes. It's all rather
Rails like.  I know a fair bit of the most recent enhancements were
inspired by some of the new RESTful features that where introduced.
There is one patch to that module I've been meaning to submit though
is transparent tunneling of PUT and DELETE methods via a POST and
_method.

> I'm sure Tim can chime in on other suggestions since he actually has
> experience with CGI::Application.

Well I think I said most of it already.

<tim/>

-- 
Timothy Appnel
Appnel Solutions
http://appnel.com/