[Gnu-arch-users] Re: Extension language

[zander]

On Fri, Oct 17, 2003 at 11:42:52AM -0700, Tom Lord wrote:
> > From: Joshua Haberman <address@hidden>
> > I personally resist the CLI-as-programmatic-interface idea for two main
> > reasons:
>
> > 1. The vast majority of programs I have encountered that use external
> > programs through a CLI have been fragile and had not very useful
> > interfaces.

This is very true; having had a indexing engine based on smbclient I can
attest that its really horrible to support different versions.
Things like global settings files turning off certain input levels can
also totally make your life horrible.
Having the application i18n-ed totally stops any keyword parsing in total.

>     > They are fragile because supplying input requires careful
>     > treatment of the shell and quoting, 
> 
> Not at all.  Not a few popular languages seem to think that the
> primary interface to subprocesses is `system(3)' which does exhibit
> the problems you describe.
...
> Normally you should use subprocess mechanisms that don't involve a
> separate shell at all and I'll point to two examples:
> 
>       SCSH process notation (the whole ball of wax in a neat little package):
> 
>         http://www.scsh.net/docu/html/man-Z-H-3.html#node_chap_2

Thats a nonsense suggestion; for starters since it only works from c/c++
Does it work from Java? Perl? Python?
We were talking about support from several programming languages; this
won't cut it.

>     > and output requires careful parsing of flat text to create data
>     > structures.  
> 
> That is fundamentally a feature because it allows output to be viewed
> from multiple perspective, e.g., where `grep' sees lines, `tsort' and
> `join' see fields and so forth.

We are talking about how to get data structures from the command into an
application that can then do something with it; the grep,join and other
data-manipulation cases are done in that application. Besides your point
does not take away the perfectly valid reason that output formats change.

XML was not invented for nothing, look at the problems it solves; these
are exactly the problems you get when communicating with applications via
stdin/stdout.

> I'm all for structured I/O of this or that sort, but the need to parse
> something is not, in and of itself, a source of fragility.
Changing formats, output types being added in versions, machines that
have utf8 as encoding standard, while others use cyrillic, a global
configfile that turns off output, i18n-ed output formats.
need I go on?

>  (What
> might sources of fragility are poorly designed or documented formats,
> formats that change rapidly, and the absense of help from a compiler
> that warns you when an interface has changed -- such problems have
> reasonable solutions, though.)

what is the compiler implication doing here?  We are talking about parsing
output of an application verses talking to an library via an API.
Changing an API is actually considered bad practice; nobody cares if
the in/output format from an application is changed.

> It does not, in all instances, but even when it does: how does that
> "reduce portability"?

Because SuSE has commands installed in /opt while debian has it /usr/share
The point is; libraries dont have that problem; the lib is either there
or it is not.  Libraries have a global search path; and if you choose
to not use a shell, commands don't; they need an absolute path!

> Generally speaking, providing configuration
> options that say where to look for a particular binary _increases_
> portability.

Cool idea; but not usefull and really user-unfriendly.  From experience I
can tell you users close a cd-burner that asks them where mkisofs is, and
the look for an application that does actually work.

> > Do you intend to increasingly depend on
> > a POSIX environment, such that the possibility of running on (say)
> > Windows without Cygwin becomes more remote?
> 
> Why not?

Amazing standpoint; if you want to make a living; consider that most companies
have at least a couple of Windows machines doing development.  If anyone
wants to use arch; it _has_ to be usefull on Window.s

>   In the worst case, supposing a native windows port suddenly
> became highly desirable,
It already is.  I'm looking for ways to get Windows boxes to talk to arch
repositories; I'm hoping for usable CVS itegration. If it proves to be
impossible, we won't use arch. Period.

> the system is small enough to reimplement
> from scratch.

Code duplication galore!


Your suggestions are workarounds and show a lack of experience on broader
issues then shell programming.  I suggest you try using a solaris machine
for some time and find out what non-gnu tools are like.
I also feel you are defending on a basis other then technical issues; it
would really be wise to pay attention to well argumented cases and not just
blow them away because *you* never had problems like the ones described.

-- 
Thomas Zander

pgppP0E6TYqsN.pgp
Description: PGP signature