In the near future, when flickr did not yet offer a
terabyte for storing photos, and BitTorrent Sync only appeared on the Internet screens in its insecure alpha version, I had a need: to share photos with friends and not only. But as usual with programmers it happens, under the word “share” it is worth much more than putting photos into VKontakte. Namely:
- Put photos somewhere on your server with a beautiful and simple web-interface.
- Simply and massively upload and download original images.
- Have the ability to differentiate access to certain albums.
- Try to connect it with the local network storage so as not to duplicate photos.
- If possible, delete the original photos from the server after some time and leave only the resized photos.
- Maximum free ! :)
After such thoughts, the idea begins to emerge in my head: “We need to create ...” - and you can no longer stop.
What are photo hosting sites now offering?
Google found a lot of cloud services for uploading photos, intended mainly for photographers (and not only). The essence of all services comes down to the fact that starting with a certain amount, you need to pay a fixed amount per month. If for six months the amount does not look big, then after two years it will be an unpleasant reminder. The analogy can be made with payment of ru-domains for 600 rubles per year in nic.ru and with a constant reminder to yourself that these domains should be transferred to other registrars already :).
On the other hand, if you already have a server, then you need to use it to the maximum. I found two projects that, in principle, would be able to fit my tasks. These are
Piwigo (formerly phpWebGallery) and
Koken . The last project was generally very pleased. But getting to know them better, I realized that this did not suit me either.
Dropbox, Skydrive, Google+ (Picasa), Yandeks.Fotki - these guys perfectly fulfilled their functions as long as there was enough space.
')
Share with friends
I want to tell you more about what the term “share” means to me. After some event (whether it is a trip to nature or a walk around the city), in which several people take part, many photos appear. After processing, pictures (300-700 MB) are sent to the local NAS (Synology DS210j). And this NAS folder should be put on the Internet so that the very friends who are in the photos download it.
Downloading / downloading through the browser such a volume is not for me.
But in the end, I want to have a link to an album that you can throw off to someone else. Well, the list of albums would also be nice to get. Simple ordinary process.
Most importantly, there must be original photographs and a normal resize without filters (not what VK and others are now offering). Then, when everyone has a 4K TV (as FullHD is now), it will be very cool to look through your photo archive and enjoy it again.
BitTorrent Sync
After I read the news about the release of the first version of BTSync for all platforms - I realized everything. In my head is clearly lined up the algorithm of work:
- Initial upload of photos takes place via BitTorrent Sync.
- The user does not care where he shares the folder and gets the readonly secret key, while he can do it on the NAS or at his place locally.
- Then the user goes to the web-based management interface and adds the album via the readonly secret key.
- The web interface sends the BTSync command to download this folder on the server. Gradually, the download to the server begins.
- At this time in the crown or else where there is a check whether everything is downloaded or not (a-la indexing files). All files, for example, are added to the database, and a reduced copy is created to them (i.e. all the meta-information is transferred from the original files to the database).
- After some time we delete the originals from the server (but! They are saved by users who managed to download).
BTSync for Linux still has no console API. But there is a web interface that can act as an API server. Armed with Go, I wrote a
console utility for working with BTSync. Well, then I made a
class for PHP. And then the thing is: write everything else;)
Eazyphoto
In my main specialty, I am a php programmer. Layout is the worst thing for me :) Therefore, taking Foundation, I tried to depict something on it.

On the main page we see a list of albums with names and dates. And on the album page - square pictures with a preview, as in dropbox. If you add a description to each photo and set its serial number, you get something like a blog. I chose the size of large photos for the web-interface just like marketer - FullHD :)
Manage albums and photos within the administrative panel. This is the enemy’s way to add a new album: just fill in the title, the start date and ReadOnly Secret.

What is it all written on?The project is written on the internal engine
Eaze . It is far from perfect, but allows you to quickly solve certain tasks in a known short period of time. It does not have normal documentation, but it is written in PHP, so in order to understand something, it’s enough to look inside (just like in the go-lang ideology :).
Database: I chose mysql, because everyone has it. Basically, these two tablets are interesting here: albums and photos

File indexing
First, I wrote an indexer for PHP: he ran through new albums, added them to the download queue in BTSync, and then ran through existing ones and added new files found. Just hang the script in cron every 5 minutes: and that would be enough. But not me.
It would be cool if the pictures were added to the database as they are downloaded. And here Go comes to the rescue.
eazyphotod
A small daemon that hangs and checks directories for new files. Creates previews for photos and saves to base. Communicates with BTSync'om. Here are its main tasks.
To implement these tasks, I used the following packages:
Having checked all the necessary functions in the demo project, I began to assemble it all into a working version. It took about two days to get the
finished result .
How it works?eazyphotod is launched via upstart (in the future I plan to redo it under the supervisord). After launch, it loads all albums into memory and starts scanning directories for new photos. In parallel with this, a gorutin is launched to monitor changes in the file system and to process HTTP requests (update the album's meta-information and add a new album to the download queue).
All requests (resize, update meta-information, event about a new file) are put in one
queue :
var SyncQueue = make(chan *SyncItem) type SyncItem struct { Album *model.Album FsPhotos model.PhotoList FullSync bool Filename string }
Therefore, there is no need to track simultaneous access to maps and other important variables. Everything goes in one common line.
Working with the database also turned out
pretty simple .
In general, if you thought to write on go, but all did not dare - my advice to you is: take and write something on it already :)
And one more thing:
according to ideology, my go-projects on github
are placed incorrectly, because Only one src folder should be root in the repository. And I have a whole project. I'm somehow not comfortable when next to the source code in the same folder are examples of configs, README.md and other supporting materials.
Total
The service copes with its tasks quite well: the repository is always online, BTSync is installed on it. After the photos are sent to the repository, the folder is added to BTSync and an album is created in the web interface - you can go to bed. The server with eazyphoto will download the photos and add them to the current album. In the morning you can go, check, and send the link to friends. And friends already, if necessary, download the originals to themselves through BitTorrent Sync.
Try collect
For those who decided to try to raise it all at home - here are the links:
- github.com/sergeyfast/eazyphoto-web - php-part
- github.com/sergeyfast/eazyphotod - the demon itself
For those who want to poke and see an exampleThe link to the demo deliberately not publish. But Yandex will help to find the words on the black plate.
All instructions
(or their similarity) are inside projects (open source such open source :).
Installing auxiliary software on the example of Ubuntu1. Install btsync:
sudo add-apt-repository ppa:tuxpoldo/btsync sudo apt-get update sudo apt-get install btsync
Port with data = 0. Port for web interface: 8888. IP: 127.0.0.1
2. Install go
I recommend through godeb
blog.labix.org/2013/06/15/in-flight-deb-packages-of-goMin version go: 1.1
3. Install eazyphotod
git clone git://github.com/sergeyfast/eazyphotod.git cd eazyphotod export GOPATH=`pwd` go get code.google.com/p/gcfg github.com/disintegration/imaging github.com/go-sql-driver/mysql github.com/howeyc/fsnotify github.com/rwcarlsen/goexif/exif github.com/sergeyfast/btsync-cli/src/btsync go build -o eazyphotod src/*.go
After that we got a binary.
I recommend to create / usr / local / eazyphotod / (user www-data), copy there eazyphotod + config.gcfg
Throw eazyphotod.conf in / etc / init / and run (after configuring config.gcfg):
service eazyphotod start
(deb-way: put the config in /etc/eazyphotod.conf, the binary in / usr / bin / eazyphotod, and specify the link to the config via the -config parameter).
Further development
I would like not to scare potential users with the admin panel, but to make it a normal web-based management interface and a simple script / installation package. But all this is relevant only with eazyphotod, because the cron and php process for geeks is clearly not the way out;)
If anyone has thoughts on the functionality or how it should all look (or suddenly someone wants to help;) - well.
Finally: lyrical digression. Take pictures, share with friends and parents. Life passes quickly, but the photo archive remains (preferably in RAID1 and an additional copy in case of an apocalypse :)) ...