Recent discussion on ReiserFS 4 has focused on theadvantages and disadvantages of VFS at the kernellevel versus the Desktop Environment (DE) level. Ibelieve network locations should be administered bythe kernel in a proposed framework called LinuxOn-Demand Network Access (LODNA), which would achieveseamless network integration regardless (or even inthe absence) of DEs, thus increasing usability.

INTRODUCTION:

When VFS is implemented at the KDE/GNOME level, weend up with the unfortunate situation where onlyapplications native to that DE can access its VFSfiles. For example, Mozilla and Firefox (which areGTK-based) can't access network locations set up underKDE (seehttps://bugzilla.mozilla.org/show_bug.cgi?id=298848).Making an application aware of non-native VFS requiresserious amount of work, not only to use the other DE'slibraries, but also to embed miniature network clientsfor every protocol the application supports.

The same problem appears in OpenOffice: even though itcan use the KDE filepicker, whenever it accesses afile on an SSH network location, a message pops upsaying "Protocol 'fish' is supported only partially.Local copy of the file will be created."

If Mozilla/Firefox and OpenOffice, which are some ofthe most popular applications and which have a strongdeveloper base, haven't yet been able to achievecross-VFS compatibility, you can be certain that otherapplications are in the same or worse situation.

These two examples show why VFS at the DE level is atemporary hack that only hides the need for suchfunctionality in the kernel. This hassle can becompletely avoided if the kernel provides standard I/Ofunctions for files in network locations(ssh/webdav/ftp/smb/...) because opening and savingnetwork files would then become completely transparent(i.e. no different from accessing a local file) fromthe application's point of view.

Having this functionality in the kernel would be ahuge usability plus: we would solve all these problemsin one swish, save application developers a lot oftime, and give users the peace of mind to know thatthey can seamlessly access their network files nomatter what application they use.

PROPOSAL: Linux On-Demand Network Access (LODNA)

Users would be able to mount network locations underdirectories they own. For example, to create a networklocation on my home computer pointing to my workcomputer (via ssh), I would do:mount -t ssh username@remote.computer.com:~ /home/username/net/remote_computer

From then on, whenever I change directory to/home/username/net/remote_computer, I would be able tosee the files in my computer at work as if they werelocal - no more need for fancy VPN!

Similarly, I would also be able to do:mount -t smbfs username@remote.computer.com:~ /home/username/net/remote_computermount -t webdav username@remote.computer.com:~ /home/username/net/remote_computermount -t ftp username@remote.computer.com:~/home/username/net/remote_computer

Advantages of LODNA:

1) Network locations would be fixed in the directorytree, rather than float around in a DE abstractionlike fish:/ .2) Remote files would be accessible by allapplications, even the shell.3) LODNA would be independent of Desktop Environments(although if present, they could provide GUIs forthings that could otherwise be done from the commandline). For example, KDE could use its existing "Add aNetwork Folder" wizard to help users mount networklocations.4) The user could give or deny other local usersaccess to his remote locations simply by setting thepermissions of the mount point (eg. chmod 700/home/username/net/remote_computer).5) LODNA would help users who want to access files ontheir Local Area Network but who don't know the exactname or IP address of the destination computer. Suchusers could use KDE's Konqueror File Manager(http://www.konqueror.org/) with the Smb4k(http://smb4k.berlios.de/) plugin to discover all thesamba servers on their LAN. They could then simplyright-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 withthe flexibility of SSH/SMB/WebDav/FTP.7) LODNA would allow users to build and manage theirown VPN client.

CONCLUSION:

Linux On-Demand Network Access (LODNA) is a proposedkernel-based method for accessing network locations.It would provide transparent, unified network accessto all applications and pave the way for highlyintuitive GUIs for managing diverse networks. As abuilt-in, multi-protocol VPN client, LODNA wouldgreatly help employees who work from home, and be amuch needed step towards making Linux viable on thedesktop.

For now, LODNA is only a concept, but the piecesneeded to make it happen already exist - they justneed to be integrated into the kernel, perhaps as aReiserFS 4 plugin or by another method. I welcome yoursuggestions!