Front page | perl.perl5.porters |
Postings from June 2006
Adam Kennedy wrote:
> Randy W. Sims wrote:
>> Adam Kennedy wrote:
>>> Carp...
>>>
>>> utf8
>>>
>>> warnings
>>>
>>> A few others, but yes, it should look something like that
>>>
>>> Level 1 - Perl, strict, Carp, warnings, utf8, a few other small things
>>>
>>> Level 2 - Level 1 + whatever is required to have a working CPAN client
>>>
>>> Level 3 - Level 2 plus a large number of other common things...
>>
>> Is the layered approach sensible past "Level 2" as opposed to grouping
>> modules by task? Or should there be anything at all past Level 2? The
>> more sets, the more work to support them. But then, it seems to be
>> much more reassuring to some users, judging from other posts, to have
>> a "supported" set of modules.
>
> Indeed. That's part of the reason for the discussion at the hackfest, to
> come up with some idea of how we handle that.
>
> Certainly 1 and 2 are straight forward.
>
> But there's less clarity on what we might include beyond that.
>
> Something like Task::StrawberryPerl (which I've uploaded in advance of
> Strawberry Perl actually existing) may be one method for achieving that.
Just to clarify, when I mentioned task oriented bundles, I intended
something along the lines of:
Task::WebDevelopoment (html, cgi, etc)
Task::Algorithms (Common algorithms and data structures)
Task::Text (Text Processing, incl Regexp)
Task::Protocols (http, ftp, etc; presumably a minimal set
of these would also be incl'd in "Level 2" for CPAN.pm;
this would be the complete package)
...
The goal mentioned most often for growing the core is that there are not
enough *officially suppported* modules; some companies have a limited
view of using any module not officially supported (although, I
personally don't see how this is different than evaluating and using
proprietary and commercial solutions: some are good, some suck, it's up
to the developer to make sure as product is suitable for use). The only
way the task oriented groupings would satisfy these users would be to
choose a namespace and close it except to a limited set of "official"
task sets, where presumably some committee would decide which sets to
produce and which modules make up each task set.
This seems the best middle of the road solution that could potentially
satisfy the minimalist group (me, incl) and the kitchen sink group.
Randy.
Thread Previous
|
Thread Next