Front page | perl.perl5.porters |
Postings from August 2001
Re: The case for SDKs
From:
Abigail
Date:
August 3, 2001 14:29
Subject:
Re: The case for SDKs
Message ID:
20010803212952.18799.qmail@foad.org
On Fri, Aug 03, 2001 at 09:32:13AM -0500, Jarkko Hietaniemi wrote:
> On Fri, Aug 03, 2001 at 10:29:26AM -0400, Andy Dougherty wrote:
> > On Fri, 3 Aug 2001, John Peacock wrote:
> >
> > > "Kurt D. Starsinic" wrote:
> > > >
> > > > What if an SDK were a Bundle that was owned by a particular
> > > > (possibly fictitious) user?
> > > >
> > > > What if core perl included a list of SDK names, descriptions, and
> > > > MD5 checksums?
> >
> > No, I think this couples them too strongly. You couldn't easily release a
> > bug-fix SDK because that would invalidate the checksum.
> > If an SDK can only be released or updated at the same time as the perl
> > core, I don't think it's sufficiently independent to fly on its own.
>
> Strongly agreed.
>
> The SDKs need to be decoupled from the core, that's the whole point,
> so that we don't need to keep adding cruft to the core.
I've talked a few times with Indy this week at YAPC::Europe about
the drawback of modules (and that would apply to SDKs as well).
Besides the points already mentioned in this thread, I'd like to
point out the following:
- Once a module is in the core, it will be there forever.
Compatability issues will make it that it stays. And that
kills any competition. If someone comes around with a
better implementation, well too bad, the older one is already
in the core and is there to stay, and another module doing
the same won't be added - not even if it's superior.
- Once a module enters the core, its author has "made it". There's
less initiative to maintain and extent the module than there would
be if there's still some form competion.
I find that CGI.pm is an example of a module that shouldn't have been in
the core. Now we have this monster doing everything under the sun with
a myriad of interfaces. Bloat, and not very efficient. But it's there
to stay - at least till perl6. And there isn't much initiative to do it
in another way, because CGI.pm is already there.
Abigail