I was thinking that we would need to build the mDNSResponder into our
server, but it seems that we should simply provide a link in our
documentation to where our users can get it at Apple if they want to
run this on *nix or Windows. We would then make using
Rendezvous/ZeroConf an optional part of our server configuration
(--with-mdns=<path>). If configured to use Rendezvous/ZeroConf, then
it would start up, announce itself and then listen for requests.
I'm not sure what your target audience is. If your user's don't mind
agreeing to the APSL by registering in order to get a user name and
password, and if they don't mind learning how to use cvs to get the
latest mDNSResponder that includes the daemon for *nix, then yes this
is one solution. However, I wouldn't recommend this. Is there a
problem with bundling the daemon with your server?
As for the client browsing without touching the network, the client
must be running a mDNSResponder for this to work? In our case, the
server and client are never on the same machine (except for testing).
I'm not sure that the machine running our server even needs
mDNSResponder at all as long as our app is listening for requests.
Most of the time the client will send packets on the network when
browsing. You can either compile the mDNSResponder code directly into
your client and server, or you can run the daemon. Either way, you'll
need the mDNSCore code from the mDNSResponder project.
Best Regards,
-Marc
_______________________________________________
rendezvous mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/rendezvous
Do not post admin requests to the list. They will be ignored.
