I've thought about this feature before too.  Since many other apps (Kodak's
album software on Windows at least) work like this, it is possible we're not
doing what users expect.

How to do this in a way that makes it easy to meet users' expectations but
allowing people to keep their photos private or world-read-only is important too.

How about a simple "checkbox" kinda of widget that says "Share this photo import with others" and then storing the database in the root of the photo storage.  When another user goes to import the same photos, f-spot will find the db there and use it's information instead of generating a new database.

Similar but not quite bug in #331953

I agree with comment #2, about keeping the photos.db under the root of the photos directory. Makes it a lot easier to backup your photos, as well as arrange for multiuser access

We need some way of making sure people don't delete the strange unreadable "photos.db" file then though.

I can see it happen, don't tell me I didn't warn everybody! :-)

(In reply to comment #5)
> We need some way of making sure people don't delete the strange unreadable
> "photos.db" file then though.
> 
> I can see it happen, don't tell me I didn't warn everybody! :-)

People can also delete /sbin/init or a myriad of things in ~.  We can't really stop people from being stupid.

If f-spot is successful though, it will prevent most people from even wanting to grub through the photos directory in the first place, so they won't even see the file.  I'm not sure, does f-spot provide an "open with..." context menu (with the standard gnome entries for images) for photos to satisfy a user's requirement to grub through the photos directory with nautilus to manipulate photos?

F-spot should be _the_ "photo tool" allowing you do do what you can in f-spot or open in another viewer, or with the gimp, or whatever else has registered itself with gnome to handle impage/*.

To stop the truely curious and ignorant (what a combination) the DB could be a dot-file (.photos.db).

Another way would also be to store the images directly into a mysql database. With that you would be able to provide a limited (only read, only store, dont delete, dont change, etc.) image access to a specific user group. You can also enable the users to access their images from whatever place they are (thumbnails should also be stored seperatley). It wouldnt be limited to your LAN. 
And you can hide the photos.db completley in a database. Therefore you wouldnt be able to delete this in error.

Another advantage would also be that you can use your fileserver in the cellar to store your images. Redundant images would be prevented, as multiple user do all access the same image for viewing.

You could also think of providing a php/perl/etc module providing access to this database if you want to be able to access the images through a website. No need to export the images to your webserver.

(In reply to comment #7)
> Another way would also be to store the images directly into a mysql database.

OMG!  Please, let's not contribute to mysql abuse.

I don't want my images tied up in a database that I have to use a stupid database client to get access to them thank-you very much.

> And you can hide the photos.db completley in a database.

So put a database into a mysql database.  ~sigh~

Sorry come off sounding so strongly about this, but this would be a complete disater, IMHO.

In the short term I'm going to use the symlink method that the original requestor used to allow my wife and I to share tags.

Is there likely to issues we both use f-spot at the same time?

It is worth considering that the ability to share tags might help the adoption of f-spot in work environments that need to share photos (and photo information).

I second the motion for a "family" option.
It even rhymes...

This is fixed for months now ! use the -b commandline option

(In reply to comment #11)
> This is fixed for months now ! use the -b commandline option
> 

Uhm.  Not quite.  Simply having a command line option to point to a database is hardly the solution.  A more complete solution would:

a) allow the specification of (multiple) databases as a GUI preference
b) resolve symlinks before storing information in the database
c) allow (maybe sqlite3 does this already) multiple people to have the database open and perform fine grained locking when needed.

as for (b) the situation is this: a common directory where photos are stored by everyone (with permissions according), say /data/photos and each user (or the system administrator) points their ~/Pictures to /data/photos.  The problem that arises from this is that when user "brian" imports, all of the pathnames in the database are ~brian/Pictures/<photos> and then when user "alice" wants to access the common database it tells her the path to pictures is ~brian/Pictures/ which will give her access problems.  If however the path in the database where /data/photos/<photos> (as would be result if the symlink were resolved) then all would be peachy.

An alternative to the problem posed in (b) is to make the directory field in the database relevant to the path that the photos are in.

In fact, it is my opinion that the photos.db files belong in the dir that the photos are in (in the root of a tree -- allowing subdirs for a single database if desired) and that f-spot should be configurable to look in multiple dirs for photos and their associated databases.

This would have the side benefit of allowing a user to share their entire database of photos complete with tags and so on simply by allowing access to the dir to another user and informing them of the dir.