Comments 12
Спасибо! Вот бы ещё полноценные cli на Java/Ruby…
Java — не моя стихия, но думаю для многопоточных серверных приложений — самое то. Хотя иногда у администраторов есть проблемы с деплоем Java приложений на сервер, т.к. они немного отличаются от unix-way.
Кстати кое какой код Glacier на Java выложил сам Amazon.
Ruby — моё личное мнение, что Ruby чаще всего используется с Rails, а без Rails, в системном программирование, с сокетами, с fork — гораздо реже.
Плюс у ruby плохо совместимы версии 1.8 и 1.9, RVM на production не был признан stable, когда я последний раз проверял — а это, опять же, проблемы с деплоем.
Поэтому выбрал Perl.
Кстати кое какой код Glacier на Java выложил сам Amazon.
Ruby — моё личное мнение, что Ruby чаще всего используется с Rails, а без Rails, в системном программирование, с сокетами, с fork — гораздо реже.
Плюс у ruby плохо совместимы версии 1.8 и 1.9, RVM на production не был признан stable, когда я последний раз проверял — а это, опять же, проблемы с деплоем.
Поэтому выбрал Perl.
Я не знаю, что есть на CPAN для AWS, но неужели там нет уже чего-либо общего для сервисов? Удивляет меня:
«Протокол работы с AWS реализуется самостоятельно, не используются сторонние библиотеки.»
Очень жду «Собственная реализация протокола — планируется сделать код ре-юзабельным и опубликовать как отдельные модули на CPAN». Возможно придётся с ним познакомиться.
«Протокол работы с AWS реализуется самостоятельно, не используются сторонние библиотеки.»
Очень жду «Собственная реализация протокола — планируется сделать код ре-юзабельным и опубликовать как отдельные модули на CPAN». Возможно придётся с ним познакомиться.
На CPAN вижу, например, модули:
в S3 используется другой «протокол» подписи запроса. В Glacier он гораздо сложнее docs.amazonwebservices.com/general/latest/gr/signature-version-4.html
Что подтверждается в исходном тексте — во всех этих модулях требуется hmac_sha1, а для glacier нужен sha256
А без Signature Version 4 — общее у S3 и Glacier — только HTTP (модуль LWP::UserAgent)
или вот, модуль для S3:
в нём до сих пор нет поддержки multipart upload. а если и будет, то где гарантия, что получится всё сделать многопоточно? Читая данные с диска только один раз, и не расчитывая TreeHash дважды для одних и тех же данных? Читать данные со STDIN?
Вообще, универсальные, CPAN модули — это здорово. Но за универсальность нужно платить. Как-то раз писал прокси на perl, где, помимо самого проксирования, child процессы общаются с main процессом и делают какие-то вычисления, статистику. После бенчмарков и оптимизации, прокси вышел быстрее сквида (в процессе бенчмарка он обращался с каждым запросом к squid. Squid потреблял 60% CPU, он 20%). Так вот, самое интересное, что самая медленная часть этого прокси — LWP::UserAgent.
Тот же модуль LWP::UserAgent — стандарт де-факто, можно сказать. Но если что-то серьёзное нунжно на нём сделать, всплывают грабли, и не одни:
stackoverflow.com/questions/73308/true-timeout-on-lwpuseragent-request-method
http://search.cpan.org/~bradfitz/LWPx-ParanoidAgent-1.02/lib/LWPx/ParanoidAgent.pm
В общем, я не особо переживал, когда делал собственные модули вместо поиска/интеграции существующих.
- Amazon::S3
- Net::Amazon::EC2
- Net::Amazon::S3
- Amazon::SimpleDB
- Net::Amazon::S3::Bucket
в S3 используется другой «протокол» подписи запроса. В Glacier он гораздо сложнее docs.amazonwebservices.com/general/latest/gr/signature-version-4.html
Что подтверждается в исходном тексте — во всех этих модулях требуется hmac_sha1, а для glacier нужен sha256
А без Signature Version 4 — общее у S3 и Glacier — только HTTP (модуль LWP::UserAgent)
или вот, модуль для S3:
в нём до сих пор нет поддержки multipart upload. а если и будет, то где гарантия, что получится всё сделать многопоточно? Читая данные с диска только один раз, и не расчитывая TreeHash дважды для одних и тех же данных? Читать данные со STDIN?
Вообще, универсальные, CPAN модули — это здорово. Но за универсальность нужно платить. Как-то раз писал прокси на perl, где, помимо самого проксирования, child процессы общаются с main процессом и делают какие-то вычисления, статистику. После бенчмарков и оптимизации, прокси вышел быстрее сквида (в процессе бенчмарка он обращался с каждым запросом к squid. Squid потреблял 60% CPU, он 20%). Так вот, самое интересное, что самая медленная часть этого прокси — LWP::UserAgent.
Тот же модуль LWP::UserAgent — стандарт де-факто, можно сказать. Но если что-то серьёзное нунжно на нём сделать, всплывают грабли, и не одни:
stackoverflow.com/questions/73308/true-timeout-on-lwpuseragent-request-method
http://search.cpan.org/~bradfitz/LWPx-ParanoidAgent-1.02/lib/LWPx/ParanoidAgent.pm
В общем, я не особо переживал, когда делал собственные модули вместо поиска/интеграции существующих.
Было бы здорово увидеть Ваши наработки в виде патчей к Net::Amazon::Glacier
Удалось связаться с автором. В общем договорились что он меня немного подождёт и потом как-то вместе реализуем модули, т.к. сам их реализовывать он пока не планирует.
Это замечательное начинание умерло?
С чего вы взяли?
Извиняюсь если не так, просто не нашел следов развития в Net::Amazon::Glacier как было упомянуто выше. Он уже умеет все перечисленное в этой статье?
а. ну статья про github.com/vsespb/mt-aws-glacier — командно-строчную программу — это не Net::Amazon::Glacier
Net::Amazon::Glacier — отдельный проект другого автора. мы какую-то мелочь делали вместе, но счас не понятно кто его развивает и куда двигается.
Сам github.com/vsespb/mt-aws-glacier развивается, но до разбивки его на какие-то модули ещё дело не дошло.
Net::Amazon::Glacier — отдельный проект другого автора. мы какую-то мелочь делали вместе, но счас не понятно кто его развивает и куда двигается.
Сам github.com/vsespb/mt-aws-glacier развивается, но до разбивки его на какие-то модули ещё дело не дошло.
Sign up to leave a comment.
Amazon Glacier: клиент на Perl с многопоточной/multipart закачкой