Mój HttpSession jest trochę "do dupy", bo uzależniony od Windowsa i jego WinInet. No cóż, potrzebowałem nas szybko jakąś łatwą i prostą obsługę sesji HTTP, wiec powstała ona taka jaka jest.
Od dawana chodzi mi pogłowie mała refaktoryzacja. Wydzielenie publicznego interfejsu i uniezależnienie się od systemu. Wersja win oparta dalej na WinInet, a wersja unixowa na cURL. Wtedy nawet Ci, co nie bardzo chcą widzieć winieta, mogą poprzez jedną flagę wykorzystać w windowsowej wersji także curla.
Skoro mielibyśmy już obsługę http, łatwo można dorzucić obsługę sesji FTP. Wszakże wininet i curl to "obsługują". Tak oto dochodzimy do sedna, mamy już http i ftp, to czemu nie dorzucić jeszcze POP3, SMTP i NNTP. Takie proste, podstawowe protokoły - mielibyśmy taką fajną bibliotekę - inet ;)
Tylko, że ani wininet ani curl nie obsługują popa i jego kuzynów. Ale to nie przeszkoda, przecież bawiłem się niedawno w obiektowe sockety i sockstream. To można by jeszcze je dorzucić.
I tak oto powstała fajna biblioteka sieciowa, oczywiście crossplatformowa ;)
Na ładnej licencji MIT, a nie żadne komunistyczne GPL-e.
Tylko czy warto? Bo przecież jest tyle innych libów sieciowych, obiektowych socketów i innych bebechów. Sam nie wiem ;)
Przepusz na Jave, będzie jak znalazł. Już od dłuższego czasu szukam czego podobnego, a oczywiście w standardowej wersji Javy nic takiego nie znajdziesz. Szybciej idzie to zaprogramować ręcznie na socketach.
Nie wymawiaj tego slowa…
Java ble… ;p
Napisalem w niej to co mialem napisac, i narazie nie spieszy mi sie do niej wracac w tym zyciu :D
Pisz mal pisz, na pewno się przyda :)
A dlaczego dwie wersje połączeń używasz ? Nie lepiej oprzeć windowsowa i unixową tylko o curl ?
Tak byloby najprosciej ;)
Ale w wiekszosci przypadkow na Windowsie wystarczy to co oferuje wininet i pozbywamy sie narzutu kodu i czasu curla.
Wiem, ze dzis mamy takie czasy, ze nikogo nie obchodzi to czy exec zajmuje 1MB czy 2MB :P
Zawsze mozna dodac przy kompilacji mozliwosc wyboru czy win version ma uzywac curla czy wininet.