develooper Front page | perl.perl5.porters | Postings from August 2001

The case for SDKs

From:
Tim Bunce
Date:
August 3, 2001 03:27
Subject:
The case for SDKs
Message ID:
20010803112647.H21286@rad.ig.co.uk
On Tue, Jul 24, 2001 at 11:15:28AM -0400, Andy Dougherty wrote:
> On Mon, 23 Jul 2001, Abigail wrote:
> 
> > But having CGI in the core, and not LWP is something I've never been
> > able to understand. I think it's very important to quit bickering over
> > each and ever module "put it in the core, don't put it in the core" and
> > first decide "what kind of standard library do we want to deliver with
> > Perl?". Once that policy has been decided, deciding whether modules Foo,
> > Bar and Baz should go in the core should be much easier.
> 
> Jarkko's posted his "policy" on more than one occasion, and it's not really
> all that different from the previous "policies".  Two things that I think
> have changed are:
> 
> 1.  Many more modules are stable and in very wide use now than was the
> case in earlier years, so there are many more reasonable candidates for
> inclusion.  (Previously, many discussions on "Foo", "Bar", and "Baz"
> eventually fizzled out when *none* was suitable for inclusion, e.g.
> because of portability or instability issues.  That's also what happened
> last time around on XML if I recall correctly.)
> 
> 2.  Jarkko's apparently been a bit more lenient on size issues than
> previous pumpkin holders, but given the size of the Encode module,
> lots of other things tend to look small :-).
> 
> Given our collective failure to get anywhere with the SDK concept, such
> "bickering", in moderation, is probably the least bad way we can consider
> such decisions.

I think there were two big mistakes in the SDK process.

One was the understanding that we should select and include only _one_
module for any given area of functionality. Thereby forcing us into
futile debates about which of several similar modules to include.

I see no problem with 'lowering the bar' of entry into an SDK.
The requirements should be simply that the module:
	is reasonably useful
	is reasonably well documented
	the interface is reasonably stable
If that means we end up with an SDK with five different date modules,
so what?

The other mistake was that we were trying to define 'the' (one) SDK.
I'd rather see multiple SDKs (web centric, database centric, xml, net, etc).
Sure they'll be overlaps, but that's a bonus not a problem.


Larry made some key points in his State of the Onion talks this year.

One I particularly liked was to the effect that perl6 should come with
almost no modules so you _have_ to install something like an SDK.
(That way installing extra stuff becomes standard practice for people
like ISPs thus lowering the resistance to it.)

Another was that multiple SDKs, defined by multiple groups, could coexist
in the same was as multiple linux distributions.


To get there from here I'd like to see a fresh SDK process started to
define multiple topic-based SDKs (plus one 'super sdk' that's simply
the sum of all the other SDKs).

After that work (including perhaps creating some process infrastructure
around the concept to aid installation of SDKs) I'd hope and expect
other people / groups / communities to start defining their own SDKs.

Tim.



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About