Het is al een hele tijd dat ik de intentie heb om Dropbox te vervangen, en wel door een open-source alternatief, en liefst gebruik makend van ssh, zodat het onder eigen beheer kan functioneren, zonder speciale services, en dan valt, volgens mij, zo ongeveer alles af. Dat wil dus zeggen dat we zelf voor een oplossing zullen moeten zorgen. Het liefst natuurlijk zonder zelf algoritmen voor synchronisatie gaan schrijven, want die zijn er al in overvloed. We moeten dus op zoek naar een goede commandline synchronizer, die goed (en automatisch!) bestanden tussen een lokale en bvb een ssh-source synchroniseert.
Het is de bedoeling een vergelijkbare ervaring als Dropbox te bieden. Bijvoorbeeld, wanneer voor de (voltooiing van) een synchronisatie een bestand lokaal gewijzigd wordt, dan moet het oudere bestand genomen worden. Dat is zeker! Want, ik gebruik dit vooral voor het synchroon houden van programma-files. Ik wil mijn werk aan een project tijdens de week niet verliezen door Eclipse te vroeg op te starten in het weekend ... Ik vraag me af of er wel een situatie is waar je het nieuwste bestand zou willen. Volgens mij enkel als je tegelijkertijd aan een bestand werkt, dan eventueel, maar dat is zoiezo geen goed idee, want dat is de taak voor een systeem als SVN. Liefst wordt er van het bestand wel een backup gemaakt.
Als eerste was er dan de kwestie van welke synchronizer te gebruiken. Hierbij is de keuze gevallen op Unison, omdat het duidelijk en gemakkelijk via argumenten op de commandolijn aan te sturen valt, en ongeveer exact doet wat ik verlang, en wel met het volgende commando:
unison server local -batch -prefer server
Dit voldoet voldoet volledig aan mijn beschrijving van daarnet, behalve de backup. Dat kan wel, maar dan backupt hij alles. Dat wil ik nog kunnen beperken. Waarschijnlijk zal dit gebeuren door een extra script te schrijven dat alle backups verwijderd, behalve de conflicten. Omdat, zeker in het begin, de keuze voor Unison redelijk absoluut was, werd mijn nieuwe synchronizer de naam Unisister mee.
Nu heb ik inmiddels eens verder gekeken naar csync, wat gebruikt wordt bij ownCloud (de client daarvan is niet geschikt, want ownCloud gebruikt WebDAV, en daar heb ik geen zin in), en die heeft in ieder geval veel minder opties via de commandline. Als de basis van Unisister af is zal ik waarschijnlijk eens kijken naar hoe csync geïmplementeerd is in de ownCloud client. Gebruikt men config-files, of opties die geen weerslag hebben in de man-files? Dat zullen we dan zien. De mogelijkheid dat er zo wel gemakkelijk met backups van conflicten gewerkt zou kunnen worden is wel aanlokkelijk. Daarnaast is er geen actieve development van Unison meer, en worden er enkel nog bugfixes meer uitgebracht, aldus Wikipedia. Daarnaast ondersteunt Unison ENKEL ssh, waardoor het moeilijk wordt voor Windows gebruikers, maar dit is in de eerste plaats een programma die IK nodig heb, en van Windows heb ik geen last :P Maar blijkbaar is het niet zo vanzelfsprekend om ssh aan de praat te krijgen onder Windows, maar uiteindelijk: dit is geen programma die, zonder dat iemand zich er mee bezighoudt, gemakkelijk geinstalleerd kan worden onder Windows. Onder Linux is iets helemaal anders, vermits de dependenties gewoon geïnstalleerd kunnen worden door de package manager.
Nu, naast de (primaire) synchronizer-backend, is er natuurlijk nog een belangrijke keuze: de taal en de GUI. De keuze van de taal was redelijk snel gemaakt. C was hier niet echt van toepassing, vermits het uiteindelijk om een GUI om een bestaand commando gaat. Java is absoluut geen optie, is een belachelijke taal als je kijkt naar het geheugengebruik. Daarnaast had ik hier toch enkel ervaring met Swing, en dat is al helemaal geen optie. Het werd eigenlijk bijna onmiddellijk Python, en de voorgaande motivatie kwam achteraf. Een moeilijker keuze is die van de GUI. Omdat ik het enigszins cross-platform wou, en vooral naar andere toekomstige programma's toe, koos ik voor wxPython. Maar, ik was in eerste instantie wel vergeten dat dit een C++ library is, en ik heb toch eerder de neiging te kiezen voor C, wanneer ik moet kiezen tussen die twee. Maar, een ander argument om voor wxPython te kiezen was dat PyGTK niet meer verder ontwikkeld wordt naar GTK 3 toe, en vermits dit toch ooit waarschijnlijk de norm wordt, leek het voor mezelf redelijk zinloos om nu PyGTK te leren gebruiken.
Ondertussen heb ik gezien dat het helemaal niet zo absurd is om GTK+ 3 te gebruiken in Python dmv PyGOobject. Daar bestaat een goede turorial voor, maar zo'n boel, ik heb geen zin om dat allemaal te gaan lezen op de PC. Veel handiger vind ik het om dit op papier te hebben, maar 140 pagina's daar begin ik niet zo graag aan. Toen dacht ik aan die persoonlijke drukdiensten waar ik ooit over las in de PCActive (dacht ik ...), en al snel vond ik inderdaad lulu, wat me bekend in de oren klonk. Enfin, ik had goesting om dat te bestellen, zeker toen ik keek naar de prijs op economy-paper. Maar, ik was de verzendkosten vergeten, maar ook: de economy optie laat enkel Digest en US Letter toe al papierformaat. Nu is het simpel, de ene is te klein, de andere te groot. Ik heb niet graag een boek vast (is toch groteorde 150) dat zo groot is, en Digest is te klein voor 80 karakters aan code. Nu is dit toch het minimum, er onder wordt het al snel absurd.
Nu, de bestaande turorial was zoiezo niet aangepast aan een limiet van 80 karakters. Dus, heb ik de broncode gedownload:
git clone https://github.com/sebp/PyGObject-Tutorial.git
Vervolgens heb ik deze aanpassingen aangebracht, en gecompileerd naar LaTeX met volgende commando:
make latexpdf PAPER=letter
Nu, spijtig genoeg lukte het niet om hier al de papiersoort aan te passen, ook niet door dit gewoon toe te voegen in de Makefile. Dus had ik ook enkele aanpassingen nodig aan de gegenereerde LaTeX-code. En, zo heb ik het boek aangemaakt. Nu nog geld overschrijven op PayPal. Het boek is well (nog) niet publiekelijk toegankelijk, maar je kan het zo ook gewoon zelf bestellen. Je moet enkel een front-cover verzorgen en je kan zo ook bijvoorbeeld kiezen om bijvoorbeeld toch Economy op US Letter te drukken, en toch gemakkelijk 2,50 euro besparen. Mocht er vraag naar zijn, of ik heb er goesting in, wil ik het wel openbaar maken. Ik zal wel proberen om er eens tijd voor te maken om de wijzigingen door te geven aan de oorspronkelijke auteur/project.
Maar enfin, ik zou het misschien lezen tijdens de examens, en dan kan ik het programma aanpassen naar native GTK. De reden is vooral omdat ik toch gemerkt heb dat het niet altijd optimaal is met wxWidgetrs om bijvoorbeeld theme-support te hebben. Ik zal daar toch echt serieus voor moeten zoeken voor specifieke iconen die wel in de icon-set zitten (de programma-iconen), maar niet in de standaard acties zitten. Ik vermoed dat dat veel gemakkelijk zal zijn met GTK. We zullen dan wel zien.