xime: Rezygnacja z profiles.xml

Ta notatka jest częścią serii xime. Zapoznaj się z pozostałymi wpisami.

Do tej pory w xime, jak też w kilku innych komunikatorach, profile opierały się na liście profili zapisanej w jednym pliku oraz strukturze katalogów, gdzie dla każdego profilu istniał katalog, w którym przechowywano wszelkie dane.

Przechowywanie podstawowych danych o profilu w postaci listy w jednym miejscu miało swoje zalety. Taką zaletą była niewątpliwie łatwość i szybkość przetwarzania informacji. Nie było skakania po katalogach i parsowania wielkich plików konfiguracyjnych każdego profilu w celu zbudowania prostej listy dostępnych profili. Zakładałem, że dane o profilu będą trzymane w jednym pliku XML wraz z ustawieniami danego profilu.

Rozwiązanie to miało także swoje wady. Dbanie o synchronizację między listą profili zapisanej w pliku profiles.xml a strukturą katalogów. Co zrobić, jeśli użytkownik skopiuje jakiś profil do innego katalogu, zmieni jego nazwę lub odzyska z jakiejś starej kopii zapasowej dane? Co zrobić, jeśli użytkownik zmieni nazwę profilu w ustawieniach, a jakiś inny katalog będzie posiadał już taką samą nazwę?

Właśnie przez takie problemy, które wymagałyby prawdopodobnie trochę skomplikowanego rozwiązania i zawiłej implementacji menadżera profili, postanowiłem zrezygnować z takiej listy na rzecz samej struktury katalogów.

W takim rozwiązaniu każdy katalog znajdujący się w lokalizacji uznanej za miejsce przechowywania profili traktowany jest jako potencjalny profil. Jeśli katalog ten zawiera odpowiedni plik - profile.xml - z podstawowymi danymi profilu (nazwa, hasło, data utworzenia, ostatniego logowania, etc.) to katalog uznawany jest za poprawny profil. W przeciwnym wypadku, jeśli plik nie zostanie znaleziony lub posiada inną strukturę to katalog jest uznawany jako uszkodzony profil i pomijany przez program.

Ten pomysł rozwiązuje większość problemów listy profili. Obsługa profili ograniczy się do operacji na strukturze katalogów, tak samo jak migracja, czy jakiekolwiek przenoszenia danych. Ręczne zmiany w strukturze katalogów profili nie wpłyną negatywnie na działanie aplikacji.

Oczywiście ręczna zmiana nazwy katalogu, spowoduje uszkodzenie profilu, wystąpi wtedy konflikt nazw - katalogu z danymi zapisanymi w pliku profilu. Będzie to wykorzystywane między innymi w zabezpieczeniach uniemożliwiających kopiowanie niektórych danych między profilami, np. w celu ich odczytania przez niepowołane osoby.

Aktualnie plik profile.xml, jak wskazuje rozszerzenie jest prostym plikiem XML, a wszelkie dane w nim zapisane są w postaci jawnego tekstu. W przyszłości newralgiczne dane będą musiały być odpowiednio zabezpieczone, choćby przez szyfrowanie całego pliku. Kwestia rozwiązania i wyboru sposobu, czy metody wymaga głębszego przemyślenia, dlatego odkładam to na późniejszy termin.

Zmiana sposobu przechowywania informacji o dostępnych profilach przeszła bezboleśnie. Testy wykazują, że wszystko działa poprawnie. Nic nie stoi na przeszkodzie, aby wrócić do dalszej pracy ;)