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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |