Re: Gnome VFS - plans for Gnome 2.8

On Mar 26, 2004, at 5:55 PM, Ian McKellar wrote:

On Fri, 2004-03-26 at 09:38, Sean Middleditch wrote:
The problem there is that Rendezvous is currently mDNS only.  This is
only a limitation of Rendezvous, which is just one implementation of
Zeroconf.  DNS-SD does not need to be limited to mDNS.

That is true. I wonder if that new dynamic DNS thing thats in recent
versions of BIND would play nicely with DNS-SD...

Yes, it will. That is why DNS-SD is so wonderful - it just works with all the existing infrastructure we have and administrators are already used to managing. :)

I believe the tmdns implementations support dyn-dns already. Several others do as well.

Apple is currently working on removing the mDNS restriction, so this
problem will be gone from Rendezvous in the future.  My personally
guess would be in the OS X 10.4 timeframe.  After that, corporate use
may pick up a lot.

Do you have any idea what mechanism they're planning on using?

No, it wasn't mentioned to me. Their CVS is all public (if you sign up for a free developer account), so it shouldn't be hard to find out.

Yay protocol agnostic API!  :)

Depending on what we want to do with it, there's no reason for it to be hard. One does have to look at the LCD situation. Namely, is all this
API going to do is allow querying for services and publishing them?

The way I envisioned it was to have a library like libgnetwork that let
you describe sockets you want to listen on and have that magically
published however we know how or describe (and obviously list) the
service you want to connect to and get a socket to that.

Well, there are a lot more to services than just sockets, unfortunately. You need to tell it which service it is, provide a short name/description of the service, provide any necessary parameters (for example, publishing my home folder over web-dav would require not just a network port, but a path as well).

Service meta-information is stored/managed differently in different
protocols.  One may need some kind of HAL-like library for this, so
that e.g. printer meta-information can be queried/provided in a uniform
fashion with the underlying library translating it to the
protocol-specific formats.

No, I think that's best taken care of at a higher level - in the case of
printing we have libgnomeprint (or ideally CUPS) to handle the various
domain-specific metadata schemas. I'm not sure how other discovery
mechanism publish metadata but dns-sd uses a simple name/value pair
list. (and a curse on whoever decided to make iChat violate the dns-sd
spec for TXT metadata).

These libraries can surely handle the specific domain parameters. But we still need a way to publich them given the service library. I.e., the key names used by DNS-SD probably have no relation to the mechanism used in UPnP.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]