[Catalyst] RFC: The paradox of choice in web development

[Stuart Watt]

Cosimo Streppone wrote:
> It's _not_ that hard.
> Perl has been good in the Windows world for long.
> Strawberry has improved this a great deal.
Actually, our experience has been pretty horrendous. The problem for us =

has not been Perl but deploying Catalyst apps under Windows. We've used =

IIS and FastCGI, which eventual hard-won success, and we now have a =

60-page installation guide as a result.

Strawberry for us had the same issues as ActiveState - a Perl =

distribution that worked fine, but neither was updated all that =

frequently, and both have no debugging support which makes memory leak =

tracing somewhere between very hard and impossible. In the end I built =

my own Perl, with MinGW, and found it only slightly harder than using =

Strawberry. This was because there had been a core bug in both =

distributions which broke DBI with a memory leak - since the indexing =

part of our app does tens of millions of SQL queries, we could never get =

it to run to completion under Windows. The time it took for the core =

patch to make it into the distribution was about four months.

On Windows, for the most part, Perl is the easy bit. Getting it to talk =

to some parts of Windows is a bit harder. Getting it to run to a =

production standard with Microsoft technology is almost unbelievably =

complex. It would probably be much easier with Cygwin, Apache, etc., but =

then, the whole point of them is to hide Windows, so that isn't really a =

help.

Some of our nasties included:

    * ActiveState's PerlEx induced memory errors in file access at a
      level below Perl -- these all went away under FastCGI
    * File locking under Windows is not always as sound as we'd like (we
      hit frequent deadlocks in KinoSearch, which depends on it)
    * CPAN installations depending on external libraries sometimes
      require help to find the right DLLs (e.g., SSL stuff, XML::LibXML,
      XML::LibXSLT) - this seems to be very non-standard across CPAN,
      with each module working entirely differently to find DLLs
    * Under MinGW, I have even had to manually edit export files to get
      DLLs working right
    * Windows permissions for FastCGI - let's not even go there! Have
      you any idea how many policy settings and permissions are involved
      in getting IIS and Perl FastCGI to work?

OK, a lot of this is not actually Perl, but you need a very solid =

background in operating systems in general, networking, DLLs, makefiles, =

etc., if you want to get the whole of Catalyst up from a solid basis.

I'd love to see a Strawberry-type distribution that included a solid =

Catalyst base and the bridge to FastCGI, preferably under both IIS and =

Apache, etc. Give it a proper installer, capable of handling enough =

about IIS/Apache configuration to get a base Catalyst application up and =

running, with decent performance under Windows. If we'd had this, we =

would have saved months of work, and this is not an exaggeration.

All the best
Stuart
-- =

Stuart Watt
ARM Product Developer
Information Balance
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090219/d8ac6=
995/attachment.htm