[cgiapp] Re: Things we talked about at YapcNA 08: (Titanium progress report)

Mark Stosberg mark at summersault.com
Tue Jul 22 15:16:13 EDT 2008


> The last the we came up with was to come up with a new/better name. I 
> have several names although they are not all mine, I would like to post 
> them here and start some discussion:
> Spark
> Titanium

I made good progress on Titanium, but then completely lost momentum about a
week after the conference. However, there's enough done that it could be useful
to publish my progress, I just don't feel great about publishing something
that's not as polished as I wanted. 

Titanium is a sub-class of CGI::Application that bundles several useful,
popular plugins by default, but has little to no code of it's own.

As part of providing a better user experience, the documentation from
CGI::Application was copied and overhauled as well. This included documenting
some key plugin features directly (since Titanium provides them directly), and
also omitting some parts of CGI::Application that are advanced or unnecessary
for common cases.

For example, it omits how to write a plugin using callbacks, and documents
using $c->redirect(), but not $c->header_type('redirect').  Those docs are not
disappearing, they are just in the more advanced/technical CGI::Application
module, and not in the more user-friendly Titanium module.

I would also like to take the user-friendliness further and bundle the
"starter" script, and ideally even be able to ship Titanium with all it's
dependencies,  so you can just unpack it in a directory and start hacking.

Because Titanium makes several more decisions and recommendations about plugins
to use, some new users will be happy that it's easier to get started with, but
some existing users will surely disagree that whatever plugin is loaded by
default.

To address that, the documentation would describe how we might use a
"Titanium::Alloy::" name space, so other people might publish sister modules,
which take the same approach, but bundle different sets of plugins by default.

Unlike "forks", CGI::Application plugins would continue to be shared between
all of these projects. 

Finally, people who have already developed a custom sub-class that they re-use
can continue to use CGI::Application, and plugins will compatible with them as
well.

A big part of my loss is momentum is that I don't need Titanium myself because
I already have a custom sub-class of CGI::App that works well. The reason to
build it is because I believe it's a good way to build quality software easily,
and I think it would help speed up development for some people. 

I think my reality is that even if I am able to follow-through on launching
v1.0, I'm not sure I have the energy to continue to lead it where I want to see
it going in terms of all-around ease of use and packaging.

If other people share this vision, perhaps we can accomplish it together. 

    Mark

-- 
 . . . . . . . . . . . . . . . . . . . . . . . . . . . 
   Mark Stosberg            Principal Developer  
   mark at summersault.com     Summersault, LLC     
   765-939-9301 ext 202     database driven websites
 . . . . . http://www.summersault.com/ . . . . . . . .




More information about the cgiapp mailing list