[MTOS-dev] Experimental Dispatcher

[Byrne Reese]

Well said. 

Thank you Tim.

On 2/5/08 12:06 PM, "Timothy Appnel" <tim at appnel.com> wrote:

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