Nathan Torkington <[EMAIL PROTECTED]> wrote: >Ask Bjoern Hansen writes: >> On Wed, 8 Jan 2003, Perrin Harkins wrote: >> Like Perrin I would like feedback on the idea before putting in my >> proposal. > >I've also been asked if anyone has a wishlist of talks they'd like to >see at the conference. Ideally they'd be "talks I'd pay money to see" >but I could live with "talks I'd like to see even though they're hard >to justify to my boss". Feel free to brainstorm here as much as you >want :-)
I've already submitted my proposal :/ But.. We've had toolkits such as HTML::Mason, AxKit, TT2, Embperl, etc., around for some time. Originally, these seem to have been developed as complete applications in and of themselves (my impression - could be wrong). But, as with anything that is well-done, they are starting to be used in ways that perhaps the developers didn't foresee. For example, we now have Bricolage, OpenInteract, and a host of others (going on memory, not web pages here) that are application frameworks using HTML::Mason, AxKit, etc., as tools just as they might use File::Spec. I can't think of a way to use Bricolage or OpenInteract in the way that they use TT2 or some other toolkit, but I look forward to the day when someone figures out how to do that. :) What I would find interesting would be some talks about what led to some of the design decisions in these frameworks. For example, why is authorization done the way it is -- what were the requirements that led to the data structures, etc? What compromises were made (e.g., speed vs. granularity)? No one authorization system can meet the needs of all applications. The application frameworks represent a lot of the design work in creating a web application. Different applications have different needs in what the frameworks must support. Going over an existing framework in this kind of detail would be instructive for those needing to decide whether to use an existing framework (and which one, if so) or to write one from scratch. One of the beauties of mod_perl is that it inherits the TMTOWTDI attitude of Perl. Unlike other environments, there isn't one framework, one exception structure, one authorization scheme. There are many. We can more easily fit our infrastructure to our application instead of our application to the infrastructure. But for mod_perl to work well, developers need to be able to make educated choices. I think most people in mod_perl understand this and are well-able to educate themselves when needed. But for someone new to Perl/mod_perl, the choices can be daunting (some complain that there are too many choices). A few talks along the line of educating people on what is there and why it is there might help them feel a bit more comfortable. -- James Smith <[EMAIL PROTECTED]>, 979-862-3725 Texas A&M CIS Operating Systems Group, Unix
