Wczoraj przed snem doznałem olśnienia jak powinna działać Echidna aka R-Drive [czyli mój programik, który sobie w C# [fuj!] dłubię, mający dodać do mojego systemu dysk R:\, którego zawartość byłaby identyczna z Google Docs].Wcześniej problem był z tym, że trudno było połączyć model dostępu do plików binarnych od strony systemu operacyjnego z tym, że te pliki przechowywane są w sieci, a ich zapis binarny może ulec zmianie.Olśnienie polegało na tym, że dotarło do mnie, że najprawdopodobniej można to zrobić tak by po stronie klienta R-Drive działał jak RAM-Dysk. Użytkownik wrzucałby plik na dysk R:\, a po jakimś czasie byłby ten plik wrzucany do Google Docs. Czyli nie działałoby to na zasadzie ciągłego synchronizowania plików, ale na robieniu tego co czas jakiś. Żeby było łatwiej synchronizacja byłaby tylko w jedną stronę, od klienta do serwera.Teraz trzeba tylko wrócić do kodowania........ ;-)
Podobne postybeta
Lekcja na dziś - żeby konfiguracja działała trzeba ją zapisywać i odczytywać ;-)
Windows++ ;-)
Olśnienie
Programowanie na Chromebooku :-)
Szkoła, a ja zaczynam rozumieć ClassLoader'a
wtorek, czerwca 29, 2010
Subskrybuj:
Komentarze do posta (Atom)
Genialna rzecz :D gdy skończysz to udostępnisz źródła czy to projekt Closed-Source? ;)
OdpowiedzUsuńPewnie udostępnię, ale nie daję na to głowy ;-) I nie wiadomo czy skończę, bo ciągle mam problemy z tym Dokan'em [to jest ten coś który powoduje, że można się podpiąć jako kolejny dysk] nie do końca jestem pewien jak wygląda procedura instalowania tego na innych komputerach. Teraz np. używam wersji 64 bitowej, a "oficjalny" build będzie raczej 32 bitowy.
OdpowiedzUsuńAle liczę, że to jednak popełnię ;-)
Jedna ważna rzecz, taki dysk byłby specyficzny bo mógłby służyć tylko do przechowywania plików ODT, DOC, ODS, XLS i podobnych, nie wszystkich możliwych, bo co prawda Google Docs na to pozwala, ale przez API jest to dostępne tylko i wyłącznie dla kont premium. Ściągania przez API takich plików w ogóle chyba nie ma.