On Fri, 12 Oct 2012, Marc Grober wrote:
> Tag! Your it, Arthur, lol.
:-) Run. Fast.
> I think you are confusing the wonderful features of unix utilities with
> the likewise wonderful creations that can be concocted from same, and
> you under value in your comment (though I know you know better, lol) the
> simplicity of the tab ;-)
No, I'm not, actually. Let's just call drupal a meta-tool, then. Even as a
meta-tool I expect exposed little knobs for me to attach arbitrary UNIX
legos of my choice, written in the architecture of my choosing. Kind of
like my e-mail client, alpine. I wouldn't like it if tried to incorporate
every possible feature internally, and it doesn't. The editor, a separate
utility, is easily replaced with vim. PGP-signing, etc., are all performed
by separate utilities that I can redefine at will. That's good UNIX design.
> Drupal is not a unix utility. Never was, never will be.
> It is akin to similar piles o scripts which are endemic to unix.
> The individual scripts tend to be small and relatively easy to parse.
> They are open and easily tweaked. The use of php means that you can
> easily interface existing scripts with scripts in whatever language you
> wish to write in, though, as I tried to suggest, if you don't like the
> Buick, don't buy it. It is unlikely that the effort spent trying to put
> that Porsche suspension in it will pay off.....
> Most importantly the underlying data can easily be employed by anything
> you wish to use as everything is a text file or in the db
Yes... and no. Parsing/tweaking -- all of which are not tool agnostic -- in
pragmatic terms could vary wildly. How many of these scripts are
completely/mostly self-contained, i.e., limited use of 'include' and
'require'? If you would like to do some sort of content transformations
without PHP are you stuck inserting system calls (which have scalability and
security repurcussions), or is there clear enough documentation to replace
the script entirely and know what query arguments need to be present,
handled, or handed off to other scripts (should the script in question do
any kind of internal fopen())?
Questions like these illustrate how extendable a framework is, and how
restricted it is to its own ecosystem. An ideal tool allows you to pipe
outputs, etc., to other tools without necessarily having to muck about with
the first tool's internals.
As a brief aside, that is something that Apache has accounted for
externally, with the ability to stack handlers in 2.x. How easy it is to
abuse that functionality with drupal's output, I couldn't guess, however.
> and an illustration of your concerns re system calls:
> http://onlamp.com/pub/a/php/2003/08/28/php_foundations.html
Which basically reasserts my concerns over PHP's lack of an execvp option.
--Arthur Corliss
Live Free or Die
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Fri Oct 12 12:01:32 2012
This archive was generated by hypermail 2.1.8 : Fri Oct 12 2012 - 12:01:32 AKDT