Re: Specf file update

Hi Steve,

I just checked in your patches 12a) and b)

On Sat, 2004-02-14 at 16:16, Steve G wrote:

<reordered to invite others to join discussion>

> Out of curiosity, is the next release going to be 0.2 or is this
> software a little more closer to a 1.0? Like maybe a 0.5? My
> thought are that the software is pretty functional; it just needs
> some error handling in certain places.

0.5 maybe was a good choice. In its current state it can announce its
name and IP's and statically defined services. It also allows any
program using the standard resolver to look up other hosts and services
in ".local". 

On the other hand, there is no way a client application could
dynamically register a service and the capabilities for service browsing
are a bit limited. The multicast responder from MacOS X seems to
implement a special socket interface for this two things. 

For service registration IMO it was more usefull to implement standard
DNS updates. An application could also use this method for service
registration with a normal unicast DNS and the stuff for parsing DNS
update packets is already present im tmdns.

Browsing is a bit harder to get via the unicast oriented local
interface, mostly because all DNS packets are limited in size (because
of the implementation and/or the unicast DNS specs). Implementing DNS
over TCP could help a bit, but even TCP answers are limited to 64kB
(this is space for about 120 answers). 

Another point not yet handled is charset conversion. mDNS uses utf-8
while i18n in uDNS is done using "punicode". 

So there is still a bit of work left over.

<back to normal order>

> Mandrake has both a redhat-release and a mandrake-release file in
> /etc. 

 Ok, I removed the rpm based check. "configure" will now detect mandrake
by the existence "mandrake-release" file. 

> ... as long as configure doesn't run twice. 

An automake generated Makefile checks whether it (or its Makefile.in) is
out-of-date whith respect to configure.in/configure. On the other side,
cvs does not check in any file if there is no visible change. So when a
change to the configure(.in) script has no effect on at least one
Makfile.in, auto* will re-generate them ... 

This is a problem with cvs check-outs only, a package built from a
proper tgz should not show this effect. 

Ciao
  Andi




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click