FlexFTP (draft)
Wiadomo, że sockety ssą. Dotknęło mnie to właśnie przy pisaniu biblioteki FTP do Apollo. Póki co traktuję to bardziej jako pilot project, niż coś do używania. Na początku pomyślałem sobie, że najłatwiej będzie wzorować się na jakiejś jawowej implementacji. Jednak wszystko co znalazłem było... Jawowe. Znaczy obsługa socketu/bufora sprowadzała się zwykle do:
-
while ((bytesRead = input.read(buffer)) != -1)
-
{
-
output.write(buffer, 0, bytesRead);
-
}
-
output.flush();
co w przypadku flashowego modelu zdarzeń się nie sprawdzi.
Aktualnie wygląda to tak, że mamy klienta FTPClient i komendy FTPCommand i odpowiedzi serwera FTPResponse. Klient wysyła podstawowe zdarzenia FTPEvent.CONNECTED po podłączeniu, COMMAND po wysłaniu komendy i RESPONSE po otrzymaniu odpowiedzi. Na czas wysłania komendy, czy raczej serii operacji komenda-odpowiedź klient jest blokowany, żeby nie wbić się w kolejkę akcji. Wiadomo taki jest FTP. Wszystkie akcje powinny dziedziczyć po klasie FTPInvoker. Jej interfejs zapewnia początek wywołania execute(), obsługę odpowiedzi responseReceived() i sfinalizowanie bieżącej transakcji finalize().
Nie wykluczone, czy może na pewno ostatecznie wyglądać to będzie zupełnie inaczej. Bo już na dzień dzisiejszy nie podoba mi sie sposób tworzenia pasywnego połączenia i implementacja eftepowych akcji. Aktualnie klient podłącza się do serwera, listuje katalogi i zwraca ich zawartość jako tablicę obiektów FTPFile, ściąga pliki na lokalny dysk i wysyła. Z wysyłaniem wiadomo jak jest. Postępu poznać w stanie nie jesteśmy. Bo Adobe se odpuścił na socketach... Więc jeśli ktoś ma wolne łącze, lub wgrywa duuuży plik będzie sobie musiał poczekać na FTPEvent.UPLOAD.
