[nycphp-talk] security? we don't need no stinkin security!
John Lacey
jlacey at att.net
Fri Dec 5 13:13:31 EST 2003
thanks -- and there is a prize for the first person who
volunteers to change the Subject line on all these posts :)
Daniel Kushner wrote:
>>he balked at the Smarty idea (performance) and your remarks
>>caught my attention --
>>
>>Daniel, are those numbers still around?
>
>
> I haven't got them (I think). I'll re-profile the code and post in on the
> New York PHP website.
>
> --Daniel
>
>
> _______________________________________________
> talk mailing list
> talk at lists.nyphp.org
> http://lists.nyphp.org/mailman/listinfo/talk
>
>From hans not junk at nyphp.com Fri Dec 5 13:18:17 2003
Return-Path: <hans not junk at nyphp.com>
Received: from londo.swishmail.com (londo.swishmail.com [209.10.110.95])
by virtu.nyphp.org (Postfix) with ESMTP id EB2EEA8603
for <talk at lists.nyphp.org>; Fri, 5 Dec 2003 13:18:17 -0500 (EST)
Received: (qmail 19322 invoked by uid 89); 5 Dec 2003 18:18:17 -0000
Received: from unknown (HELO nyphp.com) (hans not junk at nyphp.com@128.122.155.151)
by londo.swishmail.com with AES256-SHA encrypted SMTP;
5 Dec 2003 18:18:17 -0000
Message-ID: <3FD0CC2C.2080202 at nyphp.com>
Date: Fri, 05 Dec 2003 13:19:24 -0500
From: Hans Zaunere <hans not junk at nyphp.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: NYPHP Talk <talk at lists.nyphp.org>
Subject: Re: [nycphp-talk] security? we don't need no stinkin security!
References: <Pine.BSF.4.44.0312051201340.65250-100000 at emra.pair.com>
In-Reply-To: <Pine.BSF.4.44.0312051201340.65250-100000 at emra.pair.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: talk at lists.nyphp.org
X-Mailman-Version: 2.1.2
Precedence: list
Reply-To: NYPHP Talk <talk at lists.nyphp.org>
List-Id: NYPHP Talk <talk.lists.nyphp.org>
List-Unsubscribe: <http://lists.nyphp.org/mailman/listinfo/talk>,
<mailto:talk-request at lists.nyphp.org?subject=unsubscribe>
List-Archive: <http://lists.nyphp.org/pipermail/talk>
List-Post: <mailto:talk at lists.nyphp.org>
List-Help: <mailto:talk-request at lists.nyphp.org?subject=help>
List-Subscribe: <http://lists.nyphp.org/mailman/listinfo/talk>,
<mailto:talk-request at lists.nyphp.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Dec 2003 18:18:18 -0000
David Mintz wrote:
>
> On second thought:
>
> Suppose -- just hypothetically -- I write a shell script that greps the ps
> output for a user-specified string. I could say, here's my shell script
> and you're welcome to use it, but it depends on ps and grep being
> installed on your system. Is it not a good shell script? Should it have
> its own ps and grep functionality built in, independently?
I think it's key to cut a distinction between code reuse, modularity, and frameworks.
PEAR is a framework. Just as in a house, if a load-bearing beam is removed, the structure will crumble. This is the typical architecture of a framework.
However, imagine if you could build a house with no load-bearing beams. The house, and the functionality it provides, is a composite of many smaller beams - and if one is removed or changed, the structure and functionality withstands. Sure, each beam is dependent on it's peers to operate fully and deliver the ultimate functionality required, but it's not totally integrated - there might be plastic beams, wood beams, steel, etc. And, each beam can be reused to shape the total structure differently - this is a modular or component based architecture.
In essence, it's not easy, nor would it make sense [1], to only use a piece of a framework - it's all or nothing - and the PEAR/CPAN model is akin to this. It is important to remember, however, that sometimes this is the correct model - take FreeBSD ports collection... :) While there is a great deal of dependency, it's a "closed" system - no one is using the ports system to develop an ecommerce site, then a login system and a mailing list.
H
[1] because of loads of overhead in code you're never using, security issues, and maintenance issues
More information about the talk
mailing list