Re: Proposal: gnome-user-share

[Alexander Larsson <alexl redhat com>]

On Tue, 2004-11-30 at 16:41 +0100, Alexander Larsson wrote:
> I'd like to propose the gnome-user-share module for inclusion into the
> gnome desktop.

Lots of replies here, instead of replying to each mail I'll try to sum
up my standpoint in this mail. There are a couple of major points that
people have brought up, and I'll try to respond to them separately.


1. Public folder vs share-this-folder

There are two major use cases for accessing files over the
network:

The first use case is wanting to copy a file from one user on
one machine to another user on another machine. Historically this has
been done by copying the file to a floppy, moving the floppy to the
other machine and copying it to the harddisk there. Another option
theese days is to mail the file, but this is not always sensible, mail
might not be set up, you might have no, or a slow internet connection
etc. Really, "File sharing" is not the ideal name for this, perhaps it
should be called "network file transfering".

The second use case is setting up a network file share so that several
people can work on the same set of files (or sometimes so that the
same person can access it from several machines). Often you set up a
folder for some specific project, or for a specific type of
documents. The files are generally on a server-style machine which is
always on, is commonly backuped automatically and the shares support
things like ownership of files and access rights. This form of network
file access can more correctly be described as "file sharing".

gnome-user-share is targeted mainly at the first use case, and doesn't
work well for the second use case. I don't think we shouldn't support
the second use case, but I do think its better handled differently,
and complementary to gnome-user-share.

I don't think the share-this-folder approach works very well for the
first use case above, for a few reasons:
* Its hard to share just one file. You have to create a folder for it
  so that you can avoid sharing the whole folder the file is in.
* Its very hard to get an overview of what is shared, and what is
  not. This makes it easy to forget to unshare a folder when the other
  person has accessed the file. This is especially important if you
  just want to share the current version of the file, and not future
  versions as you work on it (or create new files in the same
  directory).
* In order to be able to make a decision about sharing a directory you
  need to have a fairly good idea about how file sharing works, that
  we imho shouldn't require for everyone. For instance, you have to
  understand that sharing some directories are not a good idea, and
  why. You have to understand that idea of the unix filesystem tree
  and that if some folder is shared all folders under it are shared
  (even though you generally can't see that) and that this might be a
  bad idea. It also needs complicated setup with per-folder sharing
  permissions and different passwords and/or users.

However, share-this-folder is not such a bad idea for use case
two. But, I argue that the concept of user-space filesharing itself
doesn't work well for use case two, since:
* File sharing stops when the user logs off. This is not a big problem
  for use case 1, but it is a critical problem for use case 2.
* The user-space filesharing runs as the user only. This means all
  files will be owned by that user only, and permissions etc will not
  work.
* In general when you set up something like usecase 2 you want to do
  more things, like schedule backups of it, tune performance, and
  whatnot. This basically requires a sysadmin anyway, so requiring a
  password for setting up this usecase isn't a huge problem.

So, my argument against share-this-folder in gnome-user-share goes:
Share-this-folder only works well for use case 2, but user-level
shareing itself doesn't work well for use case 2.

This really is not an argument against share-this-folder in general,
and I think a good desktop would have a way to set up normal "global"
file-sharing. This could use share-this-folder as one way of access
(although imho it also needs to have a dialog that lists all the
currently shared folders, for overview), but this would be more of a
sysadmin utility, and likely require the root password.



2. Translation of "well known" folder names

I'd like to point out that the fact that "Desktop" and "Templates" are
stored on the disk untranslated is not a mistake, or a historical
accident. It is very mich a concious design decision (although the
full design is yet to be finished). Using the translated name as the
real folder name has a lot of problems:

* The on-disk filename is static. This means that if you later switch
  locale, if the locale translation was changed, or if the translation
  to your language is added later, then the filename will be the old
  translation. (Or you could rename them on login, but that would break
  stored pathnames.)
* If the translation or locale ever changes we can't just use the
  current translation of the original filename to find the folder,
  instead we need some sort of lookaside storage that saves the
  current folder name used for each name. (Of course, such storage
  would be required in the on-disk-filenames untranslated case too,
  this is just to point out that we don't get rid of complexity.)
* The filename encoding might be different in different locales. This
  means you might not even be able to read the old filename when you
  switch to another locale. In fact, for some (admittedly weird)
  setups you might not be able to encode the current translation of
  the filename to the filesystem encoding.
* If we use on-disk translated folder names its very complicated for
  an application to find a specific folder. Many apps won't do this,
  especially the sort of quick-hack shellscripts that the unix
  community loves. This means almost everyone will eventually end up
  with an english version of the folder and a translated one. Any
  non-english users of windows will have seen this happen many times
  before. 
  Of course, with the proposed approach you instead have to use a very
  complicated way to display the translated names of these
  folders. However, this is mainly only needed in the file manager and
  the file selector. Once these are done very little other work is
  needed in other places.

Everything is not Gnome, so it would make sense for a
english-on-disk-translations-somewhere-else setup to be standardized
on freedesktop.org, so that other apps could use it too. 

Then there is the terminal. Personally I'm not sure having english
names in the terminal is all that bad. Everything else in the terminal
is english, like binary names, program options, environment variables,
configuration file names, etc. It also makes it easy to write simple
scripts that use these well known folder names, and its easy to type
and display the filenames on dumb terminals or through network
connections where the keyboard setup or text encoding differ.

I can sympathize with people disliking adding english folder names
with some handwaving about how they will be translated in the
future. However, doing quick-hacks for special-cases of this now will
result in problems when the real solution is implemented. Maybe now is
a good time to finishing the real solution :)



3. The filename "Public"

I'm not especially attached to the folder name "Public". I think that
is what OSX uses, but if people like another name I'm fine with
that. "Shared Files" isn't all bad, although given the usecase 1 vs
usecase 2 discussion above, the term "sharing" might not be ideal given
what we mean here.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a short-sighted Jewish cat burglar with a secret. She's a pregnant 
hypochondriac opera singer from a secret island of warrior women. They fight 
crime!