> Both interesting ideas, though perhaps not for Plucker. Incidentally, I
> deleted his note, or I'd forward it along.
I keep "most" of my relevant mail, so if necessary, I'll forward it
along.. if Norm does not object.
> However, it got me thinking about the plucker-build command line.
> (Those of you who don't use command lines can stop reading right now :-).
You mean... there's *ANOTHER* way to do it? >=)
> plucker-build foo.txt >foo.pdb
<snip>
I'm all for simplifying the obvious, however.. doesn't that
complicate your parsing routines? If I omit the redirection (which obviously
is not parsed as a command passed to the parser) your suggestion would spit
the (binary) data to STDOUT. *DEFINATELY* not something you want to enable
by default. If, however, we could somehow let the parser know that we were
going to use STDOUT and redirect it, and *IF* that redirection was omitted,
it should spit out "human readable" text or HTML to STDOUT. Let me
reiterate:
DO NOT EVER SEND BINARY DATA TO STDOUT, BAD!
> I like it! I'd like to check this in, but thought I'd see what people
> thought before doing so.
Another point though, please do not remove the -f argument to the
parser. Your redirection should be in addition to it (and a feature I
personally cannot find a use for), but it should not replace it. Also, what
do you do when there is a combination of both? Right now I can see that
using -f /tmp/csets and > csets.pdb will put the textual "dump" of errors
and reporting into csets.pdb (as ascii text) and the real Plucker database
would be in /tmp/csets.pdb, and if these were both pointed to the same
location, the latter would trash the creation of the former. Fault tolerance
is always a good design criteria.
> If we write the document to stdout AND no doc_name has been
> specified or found, the home URL is used as the doc name.
Writing the document to STDOUT is bad. For one it sends potentially
bad binary control sequences to the terminal, to the session handling the
terminal, and to the system interpreting them. Over remote, ssh, screened,
dumb-terminals, thin-clients, this would cause *VERY* unstable and undesired
results.
/d
