Re: Gnome VFS - plans for Gnome 2.8

[Sean Middleditch <elanthis awesomeplay com>]

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.

> Ian