Bill,
I'd be open to it, if it seems like we always just need to add this. I'm not
enough an expert of unicode to understand the drawbacks, or why this was done
as a plugin in the first place. Is there a drawback, for example to having it
core?
I can see at the beginning having stuff like this as stand alone dists, since
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.
Anyone?
John
>________________________________
> From: Bill Moseley <[email protected]>
>To: The elegant MVC web framework <[email protected]>
>Sent: Sunday, March 3, 2013 11:50 AM
>Subject: Re: [Catalyst] Backlog for proposed changes in next Catalyst release
>
>
>
>
>
>On Fri, Mar 1, 2013 at 9:38 AM, John Napiorkowski <[email protected]> wrote:
>
>Hey All,
>>
>>
>>http://jjnapiorkowski.typepad.com/modern-perl/2013/03/catalyst-backup-for-next-release-on-play-perl.html
>>
>>
>>
>>This is over on play Perl (http://play-perl.org/player/jnap) for your
>>comments and votes. Hope to see you there!
>
>
>I think I've asked this before, but is there any talk of native encoding
>support -- meaning make Catalyst::Plugin::Unicode::Encoding part of the
>framework? Having it a plugin makes it appear as optional, but the correct
>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
>encoding issues.
>
>
> --
>Bill Moseley
>[email protected]
>_______________________________________________
>List: [email protected]
>Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>Searchable archive: http://www.mail-archive.com/[email protected]/
>Dev site: http://dev.catalyst.perl.org/
>
>
>
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
