Re: Proposal: gnome-user-share

[Ryan McDougall <NQG24419 nifty com>]

On Thu, 2004-02-12 at 16:47 +0100, Alexander Larsson wrote:
> 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:

Breaking it into two cases is really clarifying to the debate I think.
Right now I'm of the opinion that g-u-s should accommodate both cases,
and ~/Public, share-this-file, and send-this-file-to-X have their place
in making it happen.

> 
> 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".

In the first use case, I think Alan and Mikael's Send-to UI holds the
most promise. The only conceptual overhead it holds is Addressing (which
is easy in the cell phone case since you already have all your buddies
phone numbers). So long as Send-to is limited to people/places that
safely and easily discover then all we have to do is offer a list of the
people we can find on the local area network. However I am under the
impression dynamic DNS only works on local networks, ie no one is going
to be Send-toing from New Zealand to Poland?

Pros
* sharing (ie sending) one file is easy
* no need to know about what your sharing, or where its stored. no need
to unshare a file
* in fact no understanding of sharing is needed

Cons
* how does the computer know who the file should be addressed to
(solvable via e-d-s or mDNS)
* requires you to "push" the file to someone, ie. you have to worry
about whether Bill is at his computer, and it is turned on at the moment
you decide to start sharing
* security concerns: spam and email viruses anyone? its easier to trust
something you pulled down yourself

> 
> 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.

Firstly I fail to see how this is hard from a design standpoint (it may
be hard as a technical detail). But assuming it is, then this case can
be covered by Send-to.

> * 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).

To me this is nothing more than an argument for a share browser. The
little gloved hand holding the folder (which btw is a leftover from
apple days when the "Server Icon" was a picture of a waiter's hand
holding a serving platter) is mostly useless, so lets add an icon to
network:/// with the name "Stuff I'm Showing to Anyone who Asks (Public
Files)". Is it any less discoverable than ~/Public?

In fact such a browser looks suspiciously like public:/// (though it
doesn't have to be), which I know is evil and wrong, but honestly
sorting out the problems with ~/Public in use-case-2 would probably
require VFS magic anyways.

> * 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.

I agree it isn't for everyone, however its been pointed out in other
emails that sorting out how to do sane things when adding stuff to
~/Public (without resorting to VFS magic) requires some knowledge of
unix file systems too. 

> 
> 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.

I'm not so sure its critical. In cases where you want something less
than a full file server, like when I want to share my music directory
with my wife, then its likely that we can coordinate ourselves
sufficiently as to be logged on at the same time. This is even less of a
problem in most desktop cases since there wont be multiple logins at one
computer, so a user session likely lasts as long as the computer is on
(the sharing *has* to stop when the computer turns off right?).

Its also a problem thats not too hard to understand. If I let you have
temporary access to my personal filing cabinet while I am in the office,
but I then leave the office, its logical to assume that you no longer
have access to my personal files.

> * 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.

Not always. I think that there are reasons for something less than a
full server, like sharing music or movies with the person(s) you live
with.

> 
> 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.

I'm not sure its true that it must require root, as stated above. Once
you get into root permissions, you might as well just use Samba a nice
GUI.

> 
> 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:

First let me say, that as someone caught between English and Japanese
locales, I have some experience as the user we are mostly talking about.
However, people like me who change locales are a pretty corner case.
Mostly people stay speaking whatever language the feel most comfortable
in. I DO change input quite a lot, but thats what GIMLET is for.
> 
> * 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.)

My data in my home directory is mine, and I'd quite like to name it what
I want. If I change locales, and I don't like the fact that all
directories remain in English, I'll change it manually. Why should some
of my personal folders magically change? People dislike magic things
happening to their data, even if the hard English directory name
remains.

It seems as if once we abandon the notion of magically changing user's
directories, that quite a few objects to native encoding seem to go
away?

> * 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.

This does in fact appear to be a problem.

> * 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.

Whats wrong with Environment Variables? I think bash supports unicode.
Submit some variable names to freedesktop.org, and use those.

If apps write English versions because they aren't smart enough to find
the proper place, then they are broken period.
> 
> 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.

Terminal can use unicode environment variables can't it?
> 
> 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 :)
> 

Thanks for all the awesome info Alex, you rock. I hope your inner-ear
thing get better. Take care of yourself.

Cheers,
Ryan