>>>>> "Dr.S" == shivers <shivers@cc.gatech.edu> writes:
Dr.S> Olin, we're trying to do something essentially very simple here, and
Dr.S> No, you're not. The syslog facility actually has a fair number of knobs
Dr.S> & dials, unfortunately. And I don't think my API in general use will
Dr.S> be very complex.
Well, I can't see how you can say that if you're referring to use as
in "writing code that uses it". Just look at the sheer size of your
API; users will feel that they need to read all that stuff in order to
use the syslog facility. Worse, users will not be able to *remember*
the relevant bits, but will have to wade through the docs again and
again. This along makes, for example, SRFI 1 *completely* useless to
me. Same in this case.
Dr.S> and then sprinkled throughout the app occurrences of things like
Dr.S> (syslog-write syslog-level/critical "Spool volume out of space.")
Dr.S> or
Dr.S> (syslog-format syslog-level/warning "Possible spam attempt host=~s
IP=~x"
Dr.S> host ip-address))
Why do we need syslog-format? What's wrong with
(syslog-format syslog-level/warning
(format #t "Possible spam attempt host=~s IP=~x"
host ip-address))
Not significantly longer, as understandable, easier to remember.
Dr.S> I'm not sure I understand what you mean by the above. Can you
Dr.S> explain? My API is a lot like the R5RS I/O system -- explicit
Dr.S> ports, but a dynamically-scoped way to establish a default for
Dr.S> the basic operations (input, output, logging).
Well, but R5RS doesn't define redundant macros/thunk-accepting
procedures, for one. There sure isn't a SET-CURRENT-OUTPUT-PORT!, and
that's a good thing.
Moreover, ports are conceptually different in that different output ports
refer to different output destinations. With syslog, everything ends
up in one place.
Dr.S> In the syslog case, this is useful for general-purpose libraries
Dr.S> that do logging of unusual situations.
OK, I buy that.
Dr.S> So any piece of code that wants to log a message is responsible
Dr.S> for determining the name & facility class of the top-level
Dr.S> application?
No, I'm saying that, given the complexity of the API, it's much easier
for the easier to define her own facility for communicating these
channels. (I know, I know, Jin Choi, but Perl simply doesn't have
Scheme's abstraction facilities in as convenient a syntactic form.)
Dr.S> Some of the complexity of my API comes from the fact that it
Dr.S> tries to export as much control of the underlying system as
Dr.S> possible -- and that underlying system has a lot of knobs.
Well, the syslog man page sure looks simpler to me than your API
proposal. That's no good.
Olin> Such as the NWAIT facility, which in fact is necessary for apps
Olin> that need to control the order in which they allocate file
Olin> descriptors.
But we do we need this in scsh? It's supposed to be a *high-level*
system. Who cares? (Let me again say that this whole idea of leaking
file descriptors into Scheme space was an honorable idea, but I still
haven't encountered a single application which requires it.)
Dr.S> If you *do* choose to have a "syslog channel" data type, then
Dr.S> bear in mind that all data types should support equality,
Dr.S> hashing & a type predicate.
Why? You stressed the connection with ports, which have none of
these. None of the interesting data types in scsh provide hashing.
So here's a simpler API, roughly:
(with-syslog-destination name class option thunk)
Specify dynamically-scoped default values for NAME, CLASS, and OPTION.
Ranges essentially as in your proposal [1]. #f says we'll take the
previous value.
(syslog-write level msg [name class option])
Write to the syslog. Omitted or #f NAME, CLASS, or OPTION means take
the default off WITH-SYSLOG-DESTINATION.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
[1] Well, another note: Doing bitwise-ors for option sets in Scheme is a bad
idea. Let's migrate to using Scheme 48's new native facility or
lists of symbols.
|