Re: [gnome-network]Desktop/file sharing and a case for SLP

[Rodrigo Moya <rodrigo gnome-db org>]

On Sun, 2004-01-25 at 14:48 +0100, "Miguel A. Arévalo" wrote:
> Rodrigo Moya wrote:
> > On Sat, 2004-01-24 at 19:05 +0100, "Miguel A. Arévalo" wrote:
> > 
> >>I think user filesharing must be completely in user-space (as opposed on 
> >>both kernel and/or admin space) and so Gnome should supply a user-space 
> >>filesharing daemon (some minimalist one implementing WebDAV or Samba) 
> >>implemented for example as a nautilus extension or a panel applet. And 
> >>so we can anounce it whichever port/address it is using with SLP.
> >>
> > 
> > doing this means re-inventing a new protocol/service, which we have
> > discussed for a long time about.
> 
> Well, I'm sorry but WebDAV, SMB, and SLP are widely 
> developed/implemented
>
I'm not saying the contrary. I am saying that a specific solution, even
if it uses those protocolos, but in different ports than the standard
ones, will just work with GNOME. We don't want that, so thus the need to
integrate in the existing networks, if any.

>  and easely re-usable.
>
well, I don't agree with that. How can a simple user share a directory
via NFS, or SMB?

>  OTOH using a systemwide 
> apache/nfsd server for personal filesharing is a quite new/harmfull idea 
> as the user has really no idea on how his system has this services 
> configured. It seems to me a quick and dirty hack waiting for a 
> permanent solution.
> 
we are not using an apache server, we are using what is setup in the
system. So if you've got apache running, it will allow you to share
files via apache, if NFS, SMB or NCP are setup, it will allow you to
share via those. If none is available, then we can probably fall back to
using a personal web server.

> But, of course, the final implementation will be the one selected by the 
> one who write it so this is just my .02 ¤
> 
> > 
> >>I think that making filesharing that way it will be much more secure 
> >>that the Windows or traditional UNIX style of implementing 
> >>user-file-sharing.
> >>
> >>After that we can go for a service browsing module for nautilus and so on...
> >>
> > 
> > yes, the idea is to use service discovery. We are going to merge gmdns
> > (gmdns in GNOME CVS) into libgnetwork. We were going to do this, but
> > lack of time hasn't helped, so if you want to help, it would be great if
> > you tried integrating the sources in gmdns into libgnetwork.
> > 
> > Once everything's in libgnetwork, we just need to start adding that
> > functionality to all apps, like nautilus, epiphany, galeon, etc
> 
> Well, you have just hitted me, I don't really like Zeroconf (which mdns 
> is part of), I've run quite big networks and trust me I still have 
> really bad headaches when I remember this multicast-monster 
> bandwith-eating NetBeui/NetBios-based networks that Zeroconf tries to 
> emulate. It's good for crossed cables and really small networks (even 
> over USB or Bluetooth) but nothing more. SLP is much more scalable and 
> user-friendly for medium to big networks.
> 
> But here is a proposal and I can take a look on it this week if there is 
> some agreement:
> 
> Develop a neutral api for accesing Service Discovery information with 
> differents plugins (a la NSS) for diferent SD/SL services, on the 
> resolver side we can have this modules for searching information:
> 
> - mDNS SD -> For Zeroconf (Apple and SOHO enviroments).
> -  DNS SD -> For Windows 2000 (and some services like Jabber and SMTP)
> -  SLP    -> For big networks (UserLinux) and Novell environments
> -  NetBIOS-> For Windows NT and samba2 networks
> 
> And on the other side some API for User-level services (like desktop and 
> personal file sharing, but also iChat, iTunes-like services) to register 
> on either mDNS and/or SLP.
> 
> What do you think about it?
> 
sounds great! SLP is definitely something we have been wanting to have,
only lack of time hasn't allowed us to have it, so any work towards that
is great.

There is, i case you don't know, openslp, which is a GPL implementation
of SLP. It is GPL, thus incompatible with libgnetwork, which is LGPL.

cheers