[Catalyst] Backlog for proposed changes in next Catalyst release

[John Napiorkowski]

>________________________________
> From: Bill Moseley <moseley at hank.org>
>To: The elegant MVC web framework <catalyst at lists.scsys.co.uk> 
>Sent: Monday, March 11, 2013 11:48 AM
>Subject: Re: [Catalyst] Backlog for proposed changes in next Catalyst release
> 
>
>
>
>
>On Mon, Mar 11, 2013 at 4:53 AM, Will Crawford <billcrawford1970 at gmail.com> wrote:
>
>While it's not Catalyst's fault, I've found over the years that interacting with underlying libraries, databases and legacy systems is generally easier when I *don't* try to force anything. I have custom code in place to deal with know sources of inconsistent encodings (check to see if it's valid UTF8, look up the remainder in a table painstakingly assembled over a period of time that catches a few odd MacRoman characters that show up in some of our contributors' data, fall back to latin1 or cp1252 for the remainder, leave anything else as \xNN). Everywhere else, UTF8 can be passed through quite transparently, so I don't really see the point of adding extra decoding and encoding all over the place to switch from utf8, to some internal wide character encoding, then back to utf8 again for output. One of the positive features of UTF8 has always been that code that doesn't need to identify any of those fancy accented characters can just treat it the same as
 ASCII, Latin-$WHATEVER or cp1252 without any overhead. Overall I can't see the point of forcing everything to be converted multiple times ... 
>>
>>
>
>I think we can all agree that historically encoding has been confusing, misunderstood, and frequently ignored.   And very often just done plain wrong.
>

This is exactly the problem. Part of it I think is how some many companies have trouble installing stuff from CPAN, so that don't and or don't upgrade very much.  Although this is a problem we as a community need to help with, I think this is part of why I am pushing to core the obvious stuff into Catalyst, such as to make it work more productively and correctly out of the box.

[SNIP]

>
>I have never considered any performance aspect of this.  It never shows up when we profile "slow" responses.  Plus, it's never been an optional operation.   We manipulate characters and we exchange data as bytes.  You have to convert between those.
>
>
>
>
>The plugin should be core to Catalyst.   It think it's pretty safe to add it if it only encodes if the utf8 flag is set on the body -- that should prevent double-encodings.   And having a config option to disable is easy.  And if the plugin is found on the app issue a warning.   It's possible that someone has their own modified version of the plugin using the same name.
>

I think it would be safe to core the behavior but have it off by default for the existing legacy project skeleton generator.  No doubt it might cause trouble for some people that have hacking Catalyt.pm a lot, but I'm going to go out on a limb and suggest if you've hack core you will be able to fix it.  And if not, then you shouldn't have hacked it ;)

The 5.9xxxx series will continue to err today backcompat for a while, although I would like to lay the groundwork for the features we'd like in Catalyst 6, whichi I think we all agree would be allowed to break some backward compat in the name of improving the codebase and setting the stage for future improvements.  My thinking here is that 5.9xxx would remain hacked on for security and bug fixes only, and I really hope that companies that maintain that version would step up a bit to help.  At a certain point I think companies can't expect volunteers to continue basically working for them for free ;)



>
>
>
>
>
>-- 
>Bill Moseley
>moseley at hank.org 
>_______________________________________________
>List: Catalyst at lists.scsys.co.uk
>Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
>Dev site: http://dev.catalyst.perl.org/
>
>
>