User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
Hi Tom,
I would like to second Krzys' concerns here. In our case, having a
system service be installed on client workstations would be near
impossible to justify with our customers. In some cases, the client
machines are running Terminal Server sessions, and the hoops we have
to jump through to get anything installed is, well...
Well i see, that i'm not the only one jumping through hoops ;)
And yet, since clients desktops running our software need to find our
server(s) (we have a multi-tiered solution), and we would prefer to do
this with zero configuration, it would make total sense to be able to
*fully* embed service discovery into the client application. I gather,
but don't know for sure, that one of the benefits of using the service
is that is quietly listens for all mDNS lookups on the network and
gives immediate responses if you request something that it has already
seen the answer too (a "non-chatty" optimization).
In my case, i only need this for the discovery phase at install or when
the app starts (computer reboot). Even for 500 to 1000 workstations
starting when users arrive in the morning, it would be limited to and
distributed over a 1h period i guess... and nothing compared to the
flood of STMP/POP3 and slashdot HTTP packets at this time of the day :)
But then again, if the embedded "service" is only started when the
client application starts, then I suppose it is unlikely to be seeing
any requests over the wire before it makes its own request, so linking
the discovery code into the client would net out to be a chatty
solution. Hmmm.
I'm not fond of linking the code (after hacking it to fit) in the app...
Obviously there would be licensing issues, but also the Bonjour service
could very well be already installed on the computer, or we might just
win the fight with the IT staff and get them to install it for us. So
the "embedded" mdnsresponder *SHOULD* be something optional. And last, i
think isolating it from the app, and keeping it as close to the original
source as possible would simplifiy the upgrade process (when a new
version is avail.)
Nonetheless, when you say it is "possible but not recommended", are we
looking at a whole lot of pain to make it happen because that was a
configuration you had not considered? Or will it be rather
straightforward? It looks like the dnssd DLL uses sockets to talk to
the local service -- would there be major code hacking involved to
short-circuit all this in a self-contained binary?
I think the best solution would be to have a "standalone" exe or dll
version of the service, that could be forked or spawned as a child
process by the client app, *if* the Bonjour service is not found or not
started. It could bind the socket, and be completely transparent to the
main app (Service, or child process, you'd talk to it with sockets via
the dnssd.dll).
Just a thought... but i think hacking the nt service to behave like a
child process would be far easier than embedding the whole stuff in the
app, and would isolate enough for any licensing issues.
Just my 2 cents :)
Best regards,
Krzys.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bonjour-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/bonjour-dev/email@hidden
