Re: Proposal: gnome-user-share

[Rodney Dawes <dobey novell com>]

Try epittance. With it you can can just right-click on a directory in
nautilus, and open the properties, and go to the "Sharing" tab. You can
currently only share a directory as read-only, but there are plans to
add support for read/write access, and multiple users, so some people
can write to a directory, and others can only read from it. A plug-in
API is also started, so that additional backends, such as iFolder,
samba, or appleshare could even be used. This is all still a work in
progress, but I think it better fits into the ideology of what
people want to do when sharing files, and it will allow integration with
multi-OS environments better. It also doesn't require any admin set-up
of apache with mod_dav, since it is a simple web server using libsoup.

-- dobey

On Tue, 2004-11-30 at 20:20 -0500, Sean Middleditch wrote:
> On Tue, 2004-11-30 at 18:46 -0500, Havoc Pennington wrote:
> > On Wed, 2004-12-01 at 09:20 +1000, Kai Willadsen wrote:
> > > 
> > > When the first great '$HOME as desktop' flamewar ended, the point that
> > > seemed to decide the issue in favour of ~/Desktop was the fact that
> > > there were many 3rd-party apps that (ab)used $HOME to store their own
> > > data in a user-visible fashion [1].
> > > 
> > 
> > Yes, but ~/Public *is* user documents and data just as ~/Desktop is. The
> > user can freely delete ~/Public if they don't want to put anything in
> > it. It's not like ~/Evolution where you had to have that if you wanted
> > to use Evolution.
> > 
> > $HOME should not be used for "implementation detail" files, with the
> > exception of dotfiles. Only user-should-care files. But ~/Public should
> > contain user-should-care files, so it makes sense in a $HOME non-
> > dotfile.
> 
> Well, unfortunately, I'm not sure ~/Public is really that great of an
> idea, although it certainly isn't the best one can do without huge
> amounts of hassle.
> 
> The problem is, in order to make documents public, users have to copy,
> link, or move documents there.  Unfortunately, move is the action most
> users are going to do, because it's the easiest and - drag and drop
> moves.  So, even though I have a document, and thus logically belongs in
> ~/Documents or some sub-folder, it might end up being in ~/Public on
> many users machines just because that's the only way they know to get it
> there.
> 
> The second easiest operation is copy.  So users that have that one
> figured out are now stuck with keeping the public copy up to date and
> possibly having two very large files around.
> 
> Linking is an odd concept to most people (it has no true metaphor
> outside of computers) and isn't likely to be used a lot.  Even when it
> is, to be perfectly frank, links suck in their own ways - namely because
> they end up "dangling" when you move or re-organize the real document.
> (Won't it be nice when we all have DB-based file systems where links
> point to the document ID and not arbitrary and dynamic properties like
> its relationships and title?)
> 
> The best solution really is to just mark documents or folders as
> "shared" and let the daemon find them and share them.  With Apache, this
> would pretty much mean writing a bunch of Alias directives and Directory
> access rules.
> 
> I'm thinking something along the lines of having a tool that can be told
> to "Add Path" or "Remove Path", and updates the Apache config file used
> and tells the server to reload it.