scsh-hackers
[Top] [All Lists]

Re: [Scsh-hackers] New syslog API proposal

To: shivers@cc.gatech.edu
Subject: Re: [Scsh-hackers] New syslog API proposal
From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor])
Date: 12 Feb 2001 18:04:09 +0100
Cc: scsh-hackers@lists.sourceforge.net
List-id: Discussion among the implementors <scsh-hackers.lists.sourceforge.net>
Sender: scsh-hackers-admin@lists.sourceforge.net
>>>>> "Olin" == shivers  <shivers@cc.gatech.edu> writes:

Olin> I have a new proposal for a syslog facility. The underlying
Olin> premise is that explicit opening and closing of syslog channels
Olin> (connections) should be deprecated, since providing multiple
Olin> channels typically requires multiplexing them onto a single
Olin> connection. Just create & use them, letting the run-time system
Olin> figure out how to manage them. This means that we no longer have
Olin> to have facilities for
Olin> opening-a-connection/doing-some-work/closing- the-connection in
Olin> a fashion that protects the connection-close across non-local
Olin> exits, which simplifies things a fair amount. E.g., I can punt
Olin> the analogs to (CALL-WITH-INPUT-FILE filename proc) and
Olin> (WITH-INPUT-FROM-FILE filename thunk).

Olin, we're trying to do something essentially very simple here, and
once again Dr. S has a go at the API and it blows up more than my last
batch of chocolate-chip cookies.  It's a monster now.

If you *must* handle syslog connections implicitly (which I think is a
bad idea because of the connection information stored in it), then
let's eliminate the idea of a syslog channel entirely and simply
provide 

(syslog-write level msg [name class option])

and figure out *all* of the connection-handling internally.

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla


<Prev in Thread] Current Thread [Next in Thread>