Design decisions

The following are some design decisions that I have made concerning FlickrFS and the reasoning behind them. Anyone may email me if they think they have a justification for or against any of these decisions.

Creating a Photoset

In Flickr, a user must create a new photoset AND add a photo to the photoset before it can be saved. This means that a user cannot create an empty photoset. Mkdir tries to create an empty directory (or photoset in our case) which cannot happen.

Solutions:

• Require the user to create photosets using the Flickr website.
  • Easy solution but inconvenient to the user. FlickrFS could still be used to manage photos but not photosets.
• Create empty photosets in the file system and sync with Flickr only when photoset is not empty.
  • Complex coding. Need to add empty photoset logic to the caching system and add conditionals in rmdir (when deleting the last photo of a photoset) and mkdir (to create the empty photosets).

The solution I have come up with is to create temporary placeholders for the photosets until a photo is added to the photoset. Then create the photoset after the photo has been created. This means any empty photosets will be lost when the application is exited and restarted.

Deleting a Photoset

Should removing a photoset directory delete the photos or just remove them from the photoset?

Soutions:

• Delete the photo from the flickr account.
  • Social expectation - a user might expect that this is the correct action since most file systems adhere to deleting a file completely.
• Delete photo from photoset.
  • Similar to how things work in the Flickr website.

Delete functionality is not implemented yet. I am still contemplating this one.