Opencaching Polska - Forum

Bas pisze:Hmmm, do pobierania pelnej bazy rsync w ogole nie jest potrzebny, bo i tak baza w zipie jest pelna. Poza tym ILE osob bedzie z tego korzystac? ILE razy? Wydaje mi sie, ze tylko raz i tylko nowy uzytkownik, wiec moze powiesic pelna baze na serwerze i dac link - jesli juz w ten sposob.

Nie nie, chodziło o to, żeby nic się nie zmieniło. W sensie update bazy po rsyncu tak jak obecnie (z punktu widzenia użytkownika) ale porównanie i transfer nie tysięcy plików, ale jednego (zipa). Jak będziesz sobie w ten sposób ściągał bazę, to i tak nie będziesz pobierał całego zipa, ale jego fragmenty, które się zmieniły, więc powinno być niedużo...

A nowy użytkownik - czy pobierze sobie ZIPa przez www czy rsync - to chyba bez różnicy.

filips pisze:to i tak nie będziesz pobierał całego zipa, ale jego fragmenty, które się zmieniły, więc powinno być niedużo...

Czyli taka indywidualna paczka dla kazdego? Dane od czasu ostatniej synchronizacji konkretnego usera, tak?

Tak jest optymalnie

Zmylily mnie:
- oc-zip-full
- 2 x 165 MB

Wlasnie zapuscilem synchronizacja - poszla ja kiedys - czyli OK

myslac o paczkach w zipie koncentrowalem sie na plikach html, bo dobrze sie pakuja. Czy jesli beda dolaczone wieksze jpg, to nie okaze sie, ze czas kompresji/dekompresji zrownowazy czas zysk z przesylania jednej paczki?

ja tez zapuscilem synchro - na razie idzie 1.6 - 1.38 kB/s ??

Bas pisze:
filips pisze:to i tak nie będziesz pobierał całego zipa, ale jego fragmenty, które się zmieniły, więc powinno być niedużo...
Czyli taka indywidualna paczka dla kazdego? Dane od czasu ostatniej synchronizacji konkretnego usera, tak?

Tak jest - tak działa rsync właśnie.

Tylko pytanie co będzie szybciej:
- czy tak jak jest teraz (multum plików do porównania, ale bez kompresji/dekompresji)
- porównywanie i przesyłanie (fragmentów) jednego pliku zip, ale + kompresja.

Nie mam pojęcia, wszystko trzeba przetestować...

A moze po prostu robic baze na dwa rozlaczne elementy - pliki tekstowe i te zipowac - i obrazki - tych nie ruszac. Osobno traktowac kazda grupe. Pakowanie i rozpakowywanie obrazkow chyba mija sie z celem

Bylbym za pakowaniem/przesylaniem plikow html.
Jesli pakowac obrazki, to bez kompresji (wylacznie dla paczki)

na razie pobral 2% = 2.6M i ciagnie dalej ???

@Filips: jestes pewien, ze to paczka dla mnie, a nie calosc? Dzisiaj po poludniu synchronizowalem baze, wiec niemozliwe, zeby tyle tego bylo...

Czemu ta predkosc transmisji jest tak koszmarnie mala??
Fakt, nigdy nie mialem wiekszej.

EDIT:
po pobraniu 5M zrezygnowalem - chyba jednak pobiera CALA baze, bo wykazal 3% calosci. Transfer na poziomie 1.3-1.6 kB/s

Wszedlem na Speed Test. Wynik:
Obrazek

EDIT2:
w zwyklej synchronizacji pobral 739kB - jest OK.

Słuchajcie, wyłania się obraz taki, że:
1) nowi users niech sobie ściągną jednorazowo zipa (normalnie, przez www)
2) a potem sobie po staremu dosysają rsyncem różnice

Inne opcje są albo skomplikowane albo nieułatwiające. Tak więc sądzę, że zostaniemy mniej-więcej przy bieżącym rozwiązaniu.

pozdrowienia,
F

filips pisze: Tak więc sądzę, że zostaniemy mniej-więcej przy bieżącym rozwiązaniu.

Popieram - zgodnie z zasada: dziala - nie dotykac

Nie wiem czy temat był poruszany, ale tak sobie myślę, że w związku z tym że keszy nam przybywa, nie wartałoby w bazie mieć tylko spoilerów?
Czy da się tak zrobić? Kupa zdjęć przedstawia okolicę, w terenie jest to niepotrzebne kompletnie.

ZYR pisze: Kupa zdjęć przedstawia okolicę, w terenie jest to niepotrzebne kompletnie.

Ale nie wszystkie i nie zawsze. Czesc zdjec umieszczonych jako normalne sa, jak piszesz, reklama otoczenia ale jest tez sporo dajacych podpowiedzi szukajacemu.

ZYR pisze:...w bazie mieć tylko spoilerów?

Dlaczego?
Karty pamieci sa tanie, a baza AZ tak duza nie jest. Same pliki html zajmuja 22.3 MB, zdjecia sa zmniejszone, wiec te 120 MB wiecej przy 4000 skrzynek to wzglednie niewiele...
Skad taki pomysl?

Przy okazji - nie synchronizuje sie (sprawdzalem jeszcze przed chwila) cache OP1145. Jest w bazie, ale pusty. Ostatnia modyfikacja: 11.08.

ZYR pisze:Nie wiem czy temat był poruszany, ale tak sobie myślę, że w związku z tym że keszy nam przybywa, nie wartałoby w bazie mieć tylko spoilerów?
Czy da się tak zrobić? Kupa zdjęć przedstawia okolicę, w terenie jest to niepotrzebne kompletnie.

Kiedyś był taki pomysł, ale ciężko odróżnić spoiler od nie-spoilera. Powodem tego jest fakt, że nie wszyscy (np ja) zawsze oznaczają pomocną fotkę jako "spoiler".

Ale przychylam się do zdania Basa, że rozmiar bazy - na razie, to nie problem.

Z innej beczki. Co do struktury nowej bazy. Co myślicie o takiej strukturze (np):

Kod: Zaznacz cały

OP\
OP\0\
OP\0\A\      <- i tu pliki OP0A00 - OP0AFF 
OP\0\A\obr   <- tu fotki do powyższych plików

nazwy plików fotek - mógłby być taki?:

Kod: Zaznacz cały

OP0A1F-4BFAC54E-3E1B-6BD6-88D9-5F5A0BDAAA86.jpg

filips pisze: nazwy plików fotek - mógłby być taki?:
Kod: Zaznacz cały
OP0A1F-4BFAC54E-3E1B-6BD6-88D9-5F5A0BDAAA86.jpg

Pytanie czy kazde urzadzenie odczyta pozniej taka nazwe (dlugosc, minus zamiast pokreslenia). Sadze ze moga byc problemy w niektorych telefonach.

I struktura, i fotki - jak dla mnie bardzo dobrze

Rozwojowo, bo na pewno nic sie nie zagesci w jednym katalogu.

Co do nazw plikow zdjec - dlaczego one w ogole sa tak kosmicznie dlugie i absolutnie niepraktyczne? Czy w systemie OC nie moglyby byc krotsze i "normalne", np. (OP) 115A-123, gdzie:
- OP zupelnie niepotrzebne
- 115A - numer skrzynki
- 123 - kolejny numer zdjecia. W DEC starczy na 1000 fotek (niepotrzebne), a dla HEX w zupelnosci wystarcza dwa znaki (256 miejsc to az nadto)...

Opencaching Polska - Forum

InfoNarzędzia dla geokeszera