Tmdns future work

Hi,

>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".

I've been all through the program and I think the server side is
in pretty good shape at this point. I think this project is at a
point it could release what's in cvs as 0.5 and then concentrate
on the client side during the work to 1.0.

>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.

I guess the first issue that needs to be decided is what should
be the major design influence on the client side. Supporting an
existing API, or doing something new and different?

Xinetd is the only major daemon that I know of that has built in
support for mDNS. It supports Rendezvous. I would suggest that
making a client API that works with little or no adjustments to
Xinetd would let tmdns gain a lot of acceptance. The reason I say
this is that if tmdns works with Xinetd, it should work with
anything else that links with Rendezvous. Xinetd does dynamic
registration, among other things, so it would be a good test bed.

Let's get the server code polished & released and then jump into
the client side. Does anyone else have comments? This is a major
decision for the project.

-Steve Grubb

__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html


-------------------------------------------------------
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