Porters, In January/February of this year, I took the challenge to rewrite the POSIX module. First I tried to get people interested and discuss the general short-comings of the module, which sadly stranded in pointless debates about setuid() incompatibilities: http://www.nntp.perl.org/group/perl.perl5.porters/2011/01/msg168598.html Then, under the impression that patches were welcome, I spent a few days for a full rewrite of the POSIX.pm documentation, describing where the 1200 POSIX functions can be found in Perl. Without repeating myself: http://www.nntp.perl.org/group/perl.perl5.porters/2011/02/msg168855.html Complete silence for three months followed. No-one bothered to tell me that blead was closed and how to continue. I was wondered by this attitude of core developers, really disappointing! However, beer at YAPC::EU was a good healer so I grew some courage again. POSIX.pm is a troublesome module. Aside from the manual page being mistaken in countless places and the 150 separate single line autoloading modules (which usually simply produce a "croak not implemented"), it is on a stand-still for ages. As a result, there are quite a number of packages on CPAN which IMHO should have been part of the core POSIX. For instance, the module Paul "LeoNerd" Evans mentioned today: POSIX::strptime. Also many modules provided by Leon Timmermans: POSIX::RT::SharedMem, POSIX::RT::Timer, SysV::SharedMem, ... And more: POSIX::Wide, POSIX::RT::MQ, POSIX::bsearch, etc etc. Having all these great modules for small parts of the POSIX function set separate has as big disadvantage that they do not get the same quality/ portability support as POSIX.pm. And do we want to rename POSIX.pm into "POSIX-small-subset.pm"? I see the module move in either of these two directions: 1) clean-up the module as part of perl-core. 2) give POSIX a dual-life (Zelfram's request to dual-life Carp just comes in when I write this) and let it grow. I propose to start-off with the cleaned-up POSIX as dual-life for 5.15. Then, invite the "CPAN" specialists of the missing compontents to contribute their few lines of XS to the generic POSIX.xs, let it get up-to-date. POSIX.xs/pm should only provide the bare minimum interface, mapped as narrow as possible on the functions where it can. Fancy OO models and such around these functions should not be part of this. -- Regards, MarkOv ------------------------------------------------------------------------ Mark Overmeer MSc MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.netThread Next