Please treat at greater length how your proposal differs from NFS. Hans
Vlad C. wrote: >Recent discussion on ReiserFS 4 has focused on the >advantages and disadvantages of VFS at the kernel >level versus the Desktop Environment (DE) level. I >believe network locations should be administered by >the kernel in a proposed framework called Linux >On-Demand Network Access (LODNA), which would achieve >seamless network integration regardless (or even in >the absence) of DEs, thus increasing usability. > >INTRODUCTION: > >When VFS is implemented at the KDE/GNOME level, we >end up with the unfortunate situation where only >applications native to that DE can access its VFS >files. For example, Mozilla and Firefox (which are >GTK-based) can't access network locations set up under >KDE (see >https://bugzilla.mozilla.org/show_bug.cgi?id=298848). >Making an application aware of non-native VFS requires >serious amount of work, not only to use the other DE's >libraries, but also to embed miniature network clients >for every protocol the application supports. > >The same problem appears in OpenOffice: even though it >can use the KDE filepicker, whenever it accesses a >file on an SSH network location, a message pops up >saying "Protocol 'fish' is supported only partially. >Local copy of the file will be created." > >If Mozilla/Firefox and OpenOffice, which are some of >the most popular applications and which have a strong >developer base, haven't yet been able to achieve >cross-VFS compatibility, you can be certain that other >applications are in the same or worse situation. > >These two examples show why VFS at the DE level is a >temporary hack that only hides the need for such >functionality in the kernel. This hassle can be >completely avoided if the kernel provides standard I/O >functions for files in network locations >(ssh/webdav/ftp/smb/...) because opening and saving >network files would then become completely transparent >(i.e. no different from accessing a local file) from >the application's point of view. > >Having this functionality in the kernel would be a >huge usability plus: we would solve all these problems >in one swish, save application developers a lot of >time, and give users the peace of mind to know that >they can seamlessly access their network files no >matter what application they use. > >PROPOSAL: Linux On-Demand Network Access (LODNA) > >Users would be able to mount network locations under >directories they own. For example, to create a network >location on my home computer pointing to my work >computer (via ssh), I would do: >mount -t ssh [EMAIL PROTECTED]:~ >/home/username/net/remote_computer > >>From then on, whenever I change directory to >/home/username/net/remote_computer, I would be able to >see the files in my computer at work as if they were >local - no more need for fancy VPN! > >Similarly, I would also be able to do: >mount -t smbfs [EMAIL PROTECTED]:~ >/home/username/net/remote_computer >mount -t webdav [EMAIL PROTECTED]:~ >/home/username/net/remote_computer >mount -t ftp [EMAIL PROTECTED]:~ >/home/username/net/remote_computer > >Advantages of LODNA: > >1) Network locations would be fixed in the directory >tree, rather than float around in a DE abstraction >like fish:/ . >2) Remote files would be accessible by all >applications, even the shell. >3) LODNA would be independent of Desktop Environments >(although if present, they could provide GUIs for >things that could otherwise be done from the command >line). For example, KDE could use its existing "Add a >Network Folder" wizard to help users mount network >locations. >4) The user could give or deny other local users >access to his remote locations simply by setting the >permissions of the mount point (eg. chmod 700 >/home/username/net/remote_computer). >5) LODNA would help users who want to access files on >their Local Area Network but who don't know the exact >name or IP address of the destination computer. Such >users could use KDE's Konqueror File Manager >(http://www.konqueror.org/) with the Smb4k >(http://smb4k.berlios.de/) plugin to discover all the >samba servers on their LAN. They could then simply >right-click on a server/share and select "Mount", >which would take them to the "Add a Network Folder" >wizard. >6) LODNA would combine the transparency of NFS with >the flexibility of SSH/SMB/WebDav/FTP. >7) LODNA would allow users to build and manage their >own VPN client. > >CONCLUSION: > >Linux On-Demand Network Access (LODNA) is a proposed >kernel-based method for accessing network locations. >It would provide transparent, unified network access >to all applications and pave the way for highly >intuitive GUIs for managing diverse networks. As a >built-in, multi-protocol VPN client, LODNA would >greatly help employees who work from home, and be a >much needed step towards making Linux viable on the >desktop. > >For now, LODNA is only a concept, but the pieces >needed to make it happen already exist - they just >need to be integrated into the kernel, perhaps as a >ReiserFS 4 plugin or by another method. I welcome your >suggestions! > >Cheers, >Vlad > > > >____________________________________________________ >Sell on Yahoo! Auctions – no fees. Bid on great items. >http://auctions.yahoo.com/ >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to [EMAIL PROTECTED] >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ > > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/