Is there any current thought of reworking ikiwiki CGI using
any of the suggested [[!cpan CGI::Alternatives]] in response to the
official deprecation of [[!cpan CGI desc=CGI.pm]]?

Or is it just a matter of 'hold course until [[rewrite ikiwiki in haskell]]'?

> I don't know whether Joey has any plans in this direction, but
> [[!cpan CGI]], [[!cpan CGI::Session]] and [[!cpan CGI::FormBuilder]]
> are all documented to be part of the [[plugin API|plugins/write]]
> so in the short term, I don't think anything is going to change.
> If someone works out a way to do equivalent hooks nicely in a
> different framework, that would have to be IkiWiki 4.
>
> I'm not sure how much IkiWiki would stand to gain from moving to a
> more extensive web framework: it doesn't do elaborate URL routing
> like most webapps, because it produces static HTML for as much of
> its content as possible anyway. --[[smcv]]

>> One reason for such a change (although a rewrite in haskell is a little drastic, and overlaps with "gitit") would be to allow ikiwiki to run as a shared thread under FastCGI or mod_perl, instead of forking all the time for every new user. The discussion for this is in [[todo/fastcgi_or_modperl_installation_instructions]] and [[todo/multi-thread_ikiwiki]].
>>
>> Also right now, there are serious lock contention issues in ikiwiki: any `?do=` action in the CGI is under a global lock right now (`lockwiki()`), for example, which makes scaling ikiwiki to multiple editing users a significant problem. I have seen such contention as a user on this wiki but mostly on the git-annex wiki.
>>
>> I, for one, would be happy to see some improvements in this area... --[[anarcat]]

>>> That would be a rewrite, in whatever language: IkiWiki assumes that
>>> global state is OK, and I don't think keeping existing APIs or
>>> plugins working unmodified when that changes would be feasible.
>>>
>>> It isn't on *my* to-do list, put it that way. --[[smcv]]

>> I'm on a thin pipe, but IIRC CGI.pm is simply no longer going to be bundled with Perl core, and is not deprecated in any other way. Just old, and now an explicit dependency. I may be wrong. --[[schmonz]]

>>> Yeah, that's what perldelta says. Also, in Debian, the future is already
>>> here: perl-modules Recommends libcgi-pm-perl, and libcgi-pm-perl comes
>>> before the bundled copy in the search path, so I'm already testing against
>>> an unbundled CGI.pm, and I suspect Joey is too. --[[smcv]]