Narodowe Archiwum Cyfrowe > Projekty w NAC
Projekt nr 2. Webowy program do przetwarzania plików graficznych,
Rafał Rufus Magryś:
Witam,
Bardzo dziękuję za te uwagi do NASZEGO projektu. Właśnie tak powinno być jest "nasz" i jak go najlepiej zaprojektujemy i przedyskutujemy -tym lepiej będzie działał.
O przeglądarce myślę wciąż w kontekście małych instytucji kulturalnych w których osoby boją się czegokolwiek instalować, pzeglądarka moglaby też ułatwić sam proces instalacji nowego konta a głównym Systemie. Ale prawda jest taka o jakiej pisał Michał S. czyli brak możliwości sprawdzania przez przeglądarkę uploadu. Możnaby to jakoś łatać tzn. np przez porównywanie przez skrypt obrazka wyjściowego z tym przesłanym (rozmiary) ale to jest wg mnie łatanie a nie rozwiązanie. Stąd myślę, że chyba trzeba pójść w stronę czegoś z JAVA - i uruchomianego przez usera przez aplikację. Aplikacja ta mogłaby łączyć się z systemem głównym i wykonywać, monitorować etc. aplikacje na serwerze. Taka aplikacja może monitorować stan przesyłania a w razie problemu przetrzymywać część danych ofline i synchronizować po uzyskaniu połączenia co jest istotne w przypadku malutkich archiwów gdzieś w Polsce.
Problem składowania skanów jest w tym momencie rozpatrywany tak sam jak problem licencji. Myślę, że niedługo będę mógł się podzielić pomysłami na rozwiązania tych kwestii na forum :)...
Pozdrawiam,
Michał Sawicz:
Wydaje mi się, że właśnie odpalanie czegoś w przeglądarce (tym bardziej, jeśli jest to aplet javowy) może spowodować więcej zgonów niż nieduży programik, który przecież "instalacji" jako takiej nie musi wymagać. Wystarczy go rozpakować - oczywiście przyda się graficzny interfejs instalacji.
Javę też trzeba zainstalować, do tego jak dobrze pamiętam - po angielsku, a prędkość działania czegoś takiego apletu należy podzielić przez 10 w stosunku do natywnej aplikacji pisanej w C++. Pamiętajmy o tym, że takie właśnie nieduże instytucje nie będą miały komputerów, które mogą sobie pozwolić na marnowanie mocy na uruchomienie maszyny java.
Ale chyba czegoś jeszcze nie rozumiem - chodzi o to, by taka biblioteka mogła "wykorzystać" serwer do obróbki obrazu i odebrać 'gotowy' plik? Czy chodzi o scentralizowanie miejsca przechowywania?
Myślałem, że w aplikacji klient-serwer chodzi właśnie o zebranie efektów mocy przerobowej kilku(-nastu, -dziesięciu) osób, a projekt 'standalone' miałby właśnie służyć niewielkim podmiotom...
Michał Sawicz:
Sorki za post pod postem, ale nie ma edycji...
Naszły mnie takie trzy pomysły po drodze do pracy:
1) Komunikacja między klientem a serwerem - wydaje mi się, że najlepiej będzie oprzeć ją na XMLu, najłatwiej wtedy będzie zdefiniować, jak np. 'zadanie' ma wyglądać. Nie jestem tylko pewien, czy sam plik opinać XMLem (po zakodowaniu base64 czy czym tam innym) czy wysyłać osobno. Pozwoli to osobom 'trzecim' na napisanie np. prostszego, lub wręcz przeciwnie - bardziej rozbudowanego interfejsu użytkownika czy z drugiej strony - wykorzystanie istniejącego interfejsu i podpięcie go do własnej aplikacji serwerowej. Powinna być też możliwość komunikacji po SSL, bo nikt nie zabroni ludkom używać tego przez internet, a raczej nie o to chodzi, żeby przesyłane do watermarkowania obrazki można sobie było po drodze przejąć. Można też pomyśleć o ewentualnej kompresji - jasne, że w przypadku TIFFa (z LZW lub podobnym) nie ma to wielkiego sensu, ale zdarzy się na pewno przesyłka BMP lub TIFFie bez kompresji - wtedy prosta kompresja na trasmisji może być przydatna.
2) Nic ważnego - ale może być przydatne - sprawdzenie prędkości transmisji przy połączeniu z 'serwerem'. Pani Kasi może nie wydawać się dziwne, że chce wysłać 400MB TIFFa po łączu modemowym. Jeśli nie będzie żadnej furtki, program się wykrzaczy prędzej czy później (tu kolejna sprawa - trzeba pomyśleć nad wznawianiem transmisji po jej zerwaniu) i Pani Kasia pobiegnie z krzykiem, że ona tego nie chce. Proste przesłanie kilkudziesięciu (lub -set) kilobajtów losowych znaków pozwoli nam określić, jakie są możliwości łącza - potem można ostrzec Panią Kasię, że transmisja tego pliku zajmie około 2 lata i czy na pewno chce to zrobić ;)
3) Zapomniałem... jak mi się przypomni, dopiszę.
Michał Sawicz:
3) Przypomniało mi się ;) Myślałem też o wersjonowaniu dodawanych archiwów... Wiemy wszyscy dobrze, jak łatwo klika się gdzieś niechcący usuwając jakiś obiekt, a potem głowimy się nad jego odzyskaniem. Może system przechowania sporządzić na zasadzie przyrostowej (lub bardziej - przedrostowej - tak by aktualna wersja trzymana była w pliku, a różnicowymi można było dojść do każdej poprzedniej wersji), choć to już dalsze plany, ale na początek - po prostu zapisywanie każdej kolejnej wersji pliku z możliwością podglądu, jak wyglądały poprzednie (oczywiście możliwość całkowitego usunięcia / zastąpienia też powinna być zaimplementowana, ale trudniejsza niż po prostu nadpisanie poprzedniego pliku).
Tuptus:
--- Cytat: Michał Sawicz w Wrzesień 26, 2007, ---(oczywiście możliwość całkowitego usunięcia / zastąpienia też powinna być zaimplementowana, ale trudniejsza niż po prostu nadpisanie poprzedniego pliku).
--- Koniec cytatu ---
O ile się orientuję to każdy system obsługujący wersjonowanie umożliwia cofnięcie się do dowolnego momentu w tym również przywrócenie skasowanych plików. Informacje o takich plikach przecież pozostają w informacjach o kolejnych wersjach. Inną sprawą jest kwestia rozmiaru takiego repozytorium.
Nawigacja
[#] Następna strona
Idź do wersji pełnej