[Catalyst] Backlog for proposed changes in next Catalyst release
jjn1056 at yahoo.com
Mon Mar 4 16:12:00 GMT 2013
I'd be open to it, if it seems like we always just need to add this. =A0I'm=
not enough an expert of unicode to understand the drawbacks, or why this w=
as done as a plugin in the first place. =A0Is there a drawback, for example=
to having it core?
I can see at the beginning having stuff like this as stand alone dists, sin=
ce it lets you be more agile in fixing issues with it, and all that but if =
this is stable then I can see just making it core.
> From: Bill Moseley <moseley at hank.org>
>To: The elegant MVC web framework <catalyst at lists.scsys.co.uk> =
>Sent: Sunday, March 3, 2013 11:50 AM
>Subject: Re: [Catalyst] Backlog for proposed changes in next Catalyst rele=
>On Fri, Mar 1, 2013 at 9:38 AM, John Napiorkowski <jjn1056 at yahoo.com> wrot=
>>This is over on play Perl (http://play-perl.org/player/jnap) for your com=
ments and votes. =A0Hope to see you there!
>I think I've asked this before, but is there any talk of native encoding s=
upport -- meaning make=A0Catalyst::Plugin::Unicode::Encoding part of the fr=
amework? =A0 Having it a plugin makes it appear as optional, but the correc=
t approach is to decoded all text requests and encode all text responses.
>This is fresh in my mind because last week had problems with two separate =
>moseley at hank.org =
>List: Catalyst at lists.scsys.co.uk
>Searchable archive: http://firstname.lastname@example.org/
>Dev site: http://dev.catalyst.perl.org/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Catalyst