Open paolobenve opened 6 years ago
This can wait for version 3.5 or later I think. Version 3.4 already has great features...
Yes, server_album_path
is useless in JavaScript, as far as I understand. I had planned to look at all .json
files in 3.5 and check whether exported information was useful or not.
So do you think we can release 3.4 exposing the original image with all its metadata?
Would't it be something that could prevent people from taking it into account in the future?
Yes. Those who don't want to give access to the original media only have to put them in a place that is not accessible by the web server. That's what I've done with the Debian package. In the case the computer is used by multiple users, I've set the album_path
value to /usr/local/share/media
that is owned by user myphotoshare
and made world writable. That way all users can drop content in that folder but it's content can't be seen but the web server (external users), only by the scanner.
I don't think it's a major issue for the majority of current users and there's a simple work around.
putting the albums in a place that is not accessible by the web server will result in an error when trying to download the original image, y whenever an image is shown too, if the screen is smaller that the maximum size of reduced images
I'm understanding what is said in #99 : original images shouldn't be offered to the user for privacy concerns.
However, someone could like offering them: galleries with images released in the public domain or with a very open licence.
So I'd add two options:
expose_original_image = no
expose_original_image_metadata = no
Obviously, the second option matters only if the first is set to
yes
.Behaviour with
expose_original_image
:yes
, the original image is showed like now, not fromalbums
directory but fromcache
: the scanner will put it in the cache directory, removing the metadata ifexpose_original_image_metadata
isno
no
, the scanner will not copy the original image to the cache directory, and javascript will choose the cache image only among the reduced size images, which have no metadata.This behaviour makes unuseful to export the
server_album_path
to javascript, doesn't it?Do we delay 3.4 release after this issue solved?