Re: Gnome VFS - plans for Gnome 2.8
- From: James Henstridge <james daa com au>
- To: Ian McKellar <yakk yakk net>
- Cc: Rodrigo Moya <rodrigo gnome-db org>, Sean Middleditch <elanthis awesomeplay com>, "desktop-devel-list gnome org" <desktop-devel-list gnome org>
- Subject: Re: Gnome VFS - plans for Gnome 2.8
- Date: Sat, 27 Mar 2004 11:19:28 +0800
On 27/03/04 01:15, Ian McKellar wrote:
Yep. That is partly because the specifications Rendezvous is built on
our inherently link local. The method of assigning IP addresses relies
on ARP queries to detect collisions. The serivce discovery and service
registration is all performed via link-local multicast packets (ie. ones
that a multicast router shouldn't forward between ethernet segments).
It is explicitly designed for local use :)
On Thu, 2004-03-25 at 16:52, James Henstridge wrote:
Do we know what actual large organisations are using for service
discovery right now? If no one is doing service discovery right now,
then we can probably choose the most elegant solution.
People are using Rendezvous, though basically they're only using it for
iTunes music sharing :) And for large organisations (eg: Apple) it
So it is obvious that Rendezvous in its current form isn't the solution
to everything. This isn't to say it isn't useful though.
About the only thing you could keep in a larger fixed network is DNS-SD,
but do it over normal DNS. If you wanted to support dynamic service
registration, it could be done via dynamic DNS updates. Alternatively,
an organisation might use a static DNS zone file for service discovery.
I don't doubt that you could write an API for protocol agnostic service
discovery. What is more difficult would be protocol agnostic service
registration. Do you try to register the service for all protocols?
What do you do if your name is taken in the SLP directory but not the
mDNS DNS-SD one?
I'd like to see GNOME have a protocol agnostic service discovery API,
but I'm not sure how possible that is.
Email: james daa com au
] [Thread Prev