[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Better (inc. asynchronous) DNS client (stub resolver)



On Wed, Oct 07, 1998 at 05:29:48PM +0100, Ian Jackson wrote:
> Mark W. Eichin writes ("Re: Better (inc. asynchronous) DNS client (stub resolver)"):
> > You might look at the "ares" library (Asynchronous RESolver) that Greg
> > Hudson <ghudson@mit.edu> wrote...  
> > 	athena-dist.mit.edu:/pub/ATHENA/ares/ares-0.3.0.tar.gz  
> > is the current version.  (At very least, compare notes with him...)
> 
> Thanks for the pointer.  At first, I saw your message and thought `oh
> no, all that wasted effort'.  But, I think my API is still an
> improvement because it provides a much more `cooked' interface.  Also,
> I'm not _too_ keen on the callback style of doing things, at least as
> a basic API.  You can always convert an event loop into a callback,
> but the other way round is hard.

Without looking at ares, I'd say that the form of your interface is
appropriate.  I'd have a hard time justifying this myself without a
lengthy exposition.  For anyone designing computer systems, I
recommend reading a paper by Butler Lampson...here is it...

  Butler W. Lampson.
    "Hints for Computer System Design",
    Proceedings of the 9th ACM Symposium on Operating Systems Principles,
    October 1983, pp.33-48.

On reading this paper, I discovered all of the reasons for why I knew
that the M$ way is wrong.  I highly recommend this paper for its
taxonomy of software design and for the 'hints' on how to avoid the
mistakes we've already seen.

> 
> Ian.
> 
> 
> --  
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> 


Reply to: