Evan, I think you bring up a few valid points here (although your brusk manner might be a bit of a distraction to some) but I'm glad you gave me the opportunity to review a bit the whys and hows of catalyst developments and the manner in which I'm choosing to communicate it.
First of all, you are right to say "no such thing as unicode out of the box". Personally I have no idea what unicode perfected would look like as I am not an expert on that topic and I have no developed use cases or clarity what the spec would be for a web framework. However I do think that unicode IS something that a framework should endeavor at vigorously. Previously people needing correct unicode either rolled their own (and took on the maint burden and accepted any and all security issues with it) or used the recommended plugin, or a mix of both. At this point there's 10 years of experience using Catalyst in an internationalized setting, and I'd like to try and tap that, and focus the conversation on the catalyst core, rather than have an unnumbered group of attempts floating around the darkpan. This is a first, small step toward iterating on a better unicode in Catalyst, and my hope it helps bring together people with the expertise to help drive that. Additionally, although I would personally prefer a smaller Catalyst core, what I have said it that I'd like to core stand alone discs when doing so what make it easier to move the platform in the correct direction. Trying to maintain the unicode plugin stand alone introduces a lot of complexity in the core api, which I think would prevent us from making eventual optimizations and improvements. For example, Catalyst has a feature called 'parse_on_demand' which defers parsing of HTTP post. This feature however basically makes two code paths for how a HTTP post is created, and my review of the code (just a quick look through, mind you) seems to suggest to me that the unicode stand alone plugin won't work with the parse_on_demand feature, and it seems like you'd need to have the plugin monkey patch Catalyst::Request for it to work correctly. So that's not really a great approach in my mind, and is a good example of the types of structural bindings that plugins can introduce. This stuff makes it very hard for us to evolve the API over time. So for example in the next catalyst development cycle, I will be proposing making 'parse_on_demand' the default behavior, since that will help us simplify the request cycle and allow us to better handle streaming POST or when the POST is huge and you just want a bit of it. The current system for doing this doesn't work in an event loop without hacking the underlying Catalyst::Request. I also think that for optimization, it would be ideal to defer as much processing to the point of demand, rather than do all the work upfront, which is how Catalyst currently works. I think this kind of decoupling will make it easier over the long term to make internal bits of Catalyst take advantage of an event loop should one exist. Things like migrating dispatch types to chained and deferring parsing of code as late as possible I believe will allow us to better optimized ditpatch and overall take advantage of new development paradigms. Each one is a small step toward that goal, with each step being someone useful in and of itself. This is the iterative and use case based approach to development I believe in. What I don't believe in is running off for two years to try and cut a branch of catalyst with 'perfect' unicode in it and then try to dump it on the community all at once (and likely fail due to compatibility issues). I don't believe that will work. So lets start a conversation about unicode in Catalyst, and what are the use cases we need for this to be great. Evan, since you seem to have some experience with this, I'd love your thoughts. John ----- Original Message ----- > From: Aristotle Pagaltzis <pagalt...@gmx.de> > To: catalyst@lists.scsys.co.uk > Cc: > Sent: Friday, June 14, 2013 12:03 AM > Subject: [Catalyst] Re: New Catalyst Release on CPAN! > > * Evan Carroll <m...@evancarroll.com> [2013-06-14 03:40]: >> > But the quick summary includes UTF8 support out of the box, support > ^^^^^^^^^^^^^^^^^ >> > for event loops and async code (including goodies like Websockets, >> > and all that stuff) as well as the usual assortment of documentation >> > fixes and related dependency fixes. >> >> I wish people would stop saying that in such a vague fashion. It seems > ^^^^^^^^^^^^^^^^^^^^ >> as if there is no such thing as "UTF-8" out of the box. Every > time it >> comes up and someone requests it, I see a very complex and detailed >> message by a UTF-8 wizzard about why it's not possible and why such >> a request is a stupid one. Then a few months later, I see people >> claiming it's been done in some niche area. >> >> There is Catalyst::Plugin::Unicode::Encoding >> And, Catalyst::Plugin::Unicode >> >> What's wrong with those two, and what does the core magically do now? > > There is nothing wrong with CP:Unicode::Encoding; the CP:Unicode POD has > long said what is wrong with it; John’s link explains what the core does > now. Spoiler: no magic. > > I wish people would take the time to read what they are responding to > before they respond to it. > > (And the antidote to the seeming back-and-forth about Unicode is to go > and figure out enough of how text is modelled in computers that you gain > gain the independent ability to judge what they say about it rather than > being beholden to being told what will or won’t work. You will find that > some things can be done and some things can’t be done, and that there is > no contradiction in that. There are no gurus.) > > Regards, > -- > Aristotle Pagaltzis // <http://plasmasturm.org/> > > _______________________________________________ > List: Catalyst@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/ >
_______________________________________________ List: Catalyst@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/
