{code}
From: Erik Paulson
-Subject: how to write a new condor daemon
+Subject: how to write a new HTCondor daemon
{endcode}
[This sort of happened by accident, and it's not yet complete. Please give me
feedback, I hope that it can someday be the start of getting started with the
-Condor codebase document. Also, it's nearly 3AM and I've decided that I dont
+HTCondor codebase document. Also, it's nearly 3AM and I've decided that I dont
want to proof-read the thing]
-So you want to write a new Condor daemon. Well, it happens, and it occurred
+So you want to write a new HTCondor daemon. Well, it happens, and it occurred
to me that we should have some documentation on how you do that. And when
I say documentation, I don't mean some doc++ in the daemon core headers, but a
nice narrative that stops and explains what's going on with things from time
@@ -21,17 +21,17 @@
condor_ca_server. We want our daemon to run on Windows and UNIX, and we want
it to be able to use strong authentication and encryption over the network.
-The first stop in writing a new daemon in Condor is the directory
+The first stop in writing a new daemon in HTCondor is the directory
condor_dcskel. This is the bare minimum that you need to have in a Daemon-core
based program to make it work.
Here's the first example of that explanation thing I was talking about
-earlier - what the hell is a daemon-core based program? Well, Condor Daemon
+earlier - what the hell is a daemon-core based program? Well, HTCondor Daemon
Core is just what the name suggests - it's a library that gives you the core
of a UNIX or NT server process. It gives you a platform-independent way to
create processes and react to the termination of those processes, set timers,
handle signals, and be able to easily handle client "commands" with just a few
-functions. Daemon core is goodness and light, and the parts of Condor that
+functions. Daemon core is goodness and light, and the parts of HTCondor that
don't use daemon core are unadultered evil, like the checkpoint server.
One thing that daemon core is not is threaded - =DaemonCore= is an example of
@@ -51,13 +51,13 @@
quick as you can - whenever you're not in select, nothing else can happen.
Daemon Core is also not light weight - all this goodness comes at a price, and
-Condor's libraries depend on the fact that everything is there. This has led
-a lot of the "research" code to avoid using the Condor libraries, because
-the Condor libraries are designed to write Condor daemons and tools. (For
+HTCondor's libraries depend on the fact that everything is there. This has led
+a lot of the "research" code to avoid using the HTCondor libraries, because
+the HTCondor libraries are designed to write HTCondor daemons and tools. (For
example, NeST is implemented with an entirely fresh code base. In some ways,
this sucks, because the NeST developers have to re-learn what took Todd, Derek,
Jim, Rajesh, Pete, and Mike Litzkow many years to learn. But at the same time,
-NeST is threaded.) If you're reading this because you want to write a Condor
+NeST is threaded.) If you're reading this because you want to write a HTCondor
daemon, then the question is already answered for you: you're using daemon
core.
@@ -197,7 +197,7 @@
doesn't know just what it is. If the question is, "what does CEDAR do", the
answer is "Yes". CEDAR is our all-singing, all-dancing communications library
that keeps Hao and Sonny in business full time. CEDAR stands for the
-Condor External DAta Representation library (well, maybe it does.) CEDAR
+HTCondor External DAta Representation library (well, maybe it does.) CEDAR
started out life as a replacement for XDR, which was a way to represent
data between different hosts, assuming the only thing that was portable was
bytes. Sun used it in Sun RPC (so NFS uses/ used it) - thankfully, I'm too
