DCC on Windows

Carl Stehle webmaster@instantservers.com
Fri Jan 9 20:28:34 UTC 2004


Vernon Schryver wrote:
> 
> > From: Carl Stehle <webmaster@instantservers.com>
> 
> > ...
> > I wanted to understand if the code was wanted, as there were some
> > prior indications from that this might not be such a good thing.
> > I did not know if the reasoning had changed at all from that time.
> > Also, as we would need to pretty it up, make changes to integrate it
> > more  cleanly, and support it, we only wanted to get started on that
> > if it were to be integrated
> 
> My main worry with Windows clients is how to fund support for users
> who would never consider typing `make install`.

Well, if the Spampal release with DCC happens, then I guess this
starts to become a problem sooner rather than later.

To support the added load caused by our mail server application 
(however miniscule at first), we were thinking of either setting
up a DCC server or finding someone who has already done so to 
work with, the latter probably being preferable due to our
general lack of experience with DCC.

I am not sure which way you want to see this go, but it seems to me
that long-term, DCC either needs a volunteer funding base in order
to remain free (like e.g. Spamhaus), or needs to partition into
free vs. fee services (Spamcop), or become entirely fee-based
(Cloudmark).

> 
> I'd be happy to make changes to the UNIX DCC client source that
> would ease its porting to other platforms.  However, I must be able
> to say that I've tested or at least thoroughly read and understood
> all of the code that I publish.  I'm also picky about the modified
> kernel-normal style I use and I believe that an entire package must
> use a single sytle.  That limits the code I can distribute.  Those
> limitations don't apply to links to other people's code.
> 
> In the Internet Age we all own printing presses.  One implication
> of that is that no one needs to use anyone else's presses (or web
> sites) to publish code.

Agree 100% with ground rules above, and we are willing to make
whatever changes are needed to conform. We have no desire to fork.
After testing and cleanup, we will make the first code draft
available.

> 
> >                             (in which case we would also use that as an
> > excuse to ask some internals questions; there are, ah, a few subtleties
> > in the code which we probably do not understand -- NOT about the fuzzy
> > checksumming but about the program flow and Un*x dependencies).
> 
> I'd be happy to try to answer useful questions on those topics.

Well, here are a few:
- Is F_SETFD/FD_CLOEXEC support required (instead of just closing
sockets or files)?

- Is the automatic closing of unlinked files considered a feature,
or could it be changed so that files are explicitly closed?

- Is 'link' mandatory in creating uniquely named temp files, or
can a copy operation be used instead?

> 
> > Beyond that, there are some issues with multi-threading and multiple
> > processes that may not affect our particular application, but require
> > looking into for more general use. Although we have not specifically
> > checked, I suspect supporting a DCC server is also beyond what we have
> > done so far; we do not need server mode and did not want to get into
> > that until understanding DCC much better; an integrated code base would
> > make that much easier to think about, if not actually implement.
> > ...
> 
> I've tried but failed to find a polite reaction to the notion of a
> Windows DCC server.  It would be useless and unprofitable for any
> person or organization with which I sympathize.  It might make sense
> if computers with real operating system still cost what they did
> 25 years ago, or if Microsoft's software including operating systems
> were not decades-long insults to anyone with technical knowledge
> and to Microsoft's customers.  Given the facts of the world as seen
> everywhere but from inside the barricades at Redmond and subsidiaries,
> there is no technical or business justification for a Windows DCC
> server, and plenty of reasons to be horrified.

I am not going to argue that one. 
What I was inarticulately asking was:
'Which DCC components need to be supported and tested for this
to be considered a port, and does that include server mode?'
The answer to the second part appears to be an unqualified 'No'.

-- 
Carl Stehle



More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.