Actually, if the parts of perl6 needed for Cwd and File::Copy are not well specced yet, porting them is probably a very useful place to start in terms of getting perl6 ready for prime time. Even if I'm not successful at porting them in the first pass, the questions and problems I come up with may help get the IO and OS interactions better specced and better implemented.
I'll look at the November CGI stuff. And explore the various XML options. Considering the customer environment my current product was developed for, and the problems (partly political) with getting access to additional CPAN modules, the perl6 community is going to need either some method for certification of modules, or a good method for including them in an application's distribution package and installing them onto the end user's machine. Supporting Windows is going to be a major pain for me, I'm sure. On Sunday 12 October 2008, Moritz Lenz wrote: > Elyse M. Grasso wrote: > > I was able to surface long enough to review the use of perl modules in our > > current, perl5-based architecture. And the answer is that we hardly use any, > > because it was written against an old version of perl5 shipped with a very > > limited set of modules and little or no ability to add CPAN modules. > > That hurts :( > > > Even my CGI accesses use Socket.pm, not CGI.pm which wasn't available for my > > customer's users. The only other module used in the existing main product is > > the proprietary CQPerlExt.pm which will be a problem in any case. And the > > install/configure tool uses Cwd and File::Copy. > > > > For the new architecture, I will need an XML parser, preferably with DTD > > validation. From reviewing the parrot and pugs source trees, it looks like > > there is already progress toward providing that functionality. (An XML writer > > might be useful, but isn't critical. I've generated a lot of XML using print > > statements over the past few years.) > > If you like XML::LibXML, you could use parrot's NCI to wrap libxml for > Perl 6. There are a few examples of Rakudo using C libraries (namely for > MySQL and xlib), so the basic functionality is there. > > > I would like to use an official CGI.pm, if one is available. > > Please forget about the "official". Perl 6 will hopefully have multiple > implementations, and they are all "official" if they pass the test suite. > > From what I've gathered so far, Perl 6 core will only be shipped with > the modules needed to install more modules, for which CGI certainly > isn't needed. > > Besides the pugs and parrot repository there's also the November wiki > [1] project, which contains a basic, working CGI module, as well as a > very basic HTML::Template implementation. > > [1] http://github.com/viklund/november/tree/master > > > If there is no one already working on porting Cwd or File::Copy, I will make > > porting those to perl6 my introduction to serious perl6 work. Please let me > > know if either of them is made redundant by new features in perl6. I have been > > reviewing the faqs and wikis to refresh my memory about the new design, but > > might have missed something. > > As much as I appreciate your enthusiasm, I'm not sure that Cwd or > File::Copy are good places to start, because they rely largely on IO and > interaction with the OS, both of which aren't very will specced, and not > very well implemented either. > > CGI is a much better start, because it can be done in pure perl. > > Most perl hackers agree that the parameter parsing and the HTML > generation part of perl 5's CGI.pm should be split up into two modules, > because they are only weakly coupled, and if you use only of them the > other half is bloat for you. > > > And if anyone is working on CGI or XML and wants a tester, please let me know. > > I'm sure the November hackers welcome more tests for CGI (cc-ing their > mailing list). > > > > -- > Moritz Lenz > http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/ > -- Elyse Grasso CTO ReleaseTEAM Inc. http://www.releaseteam.com phone 720-887-0489 fax 720-977-8010 cell 303-356-2717
