Вот выдержка из похожего исследования годовой давности (стиль вольный). Может чем-то поможет.
Хотя за год многое уже могло измениться.
Поставленная задача — найти РФС, которая:
1. поддерживает прямой доступ к файлам (отдача мелких файлов веб сервером напрямую)
2. репликацию файлов для надежности (от 2 копий, настраиваемое)
3. простое включение и выключение дисков и серверов в/из кластера
4. автоматическую реконфигурацию кластера при изменении/сбое диска, сервера
5. собственное обеспечение для защиты от сбоев серверов с основными частыми…?
Поискал в инете и нашел много-много всяких разных РФС.
Выбрал те, которые:
* бесплатные (и если можно свободные)
* не требуют изменения OS для всей системы или специализированного оборудования
* за которые глаз зацепился или название показалось знакомым
Индийская фигня.
Индийская потому, что все базовые программеры с индийскими именами,
а фигня потому что обеспечивает только часть нужной функциональности,
1.х вышла давно, а 2.0, которая и обеспечивает нужное, в состоянии беты.
интересная штука. Для _тысяч_ серверов с данными,
над которыми совершаются (здесь хочется написать надругательства) вычисления.
Для нашего обычного стораджа это слишком.
Причем приоритетными, что явно сказано в документации, считаются большие гигабайтные файлы.
Статику обрабатывать никак нельзя.
Более-менее отвечает нашим запросам, НО
— изменяется урлы для доступа к файлам
— написана на перле, использует для хранения данных о кластере Mysql (что приводит к еще одной точке отказа?).
Кстати, ФС сервера являются простыми вебдав серверами. :)
Мега гигант. Встраивается в ядро, демоны являются модулями ядра,
патчат ext3 для улучшения производительности, несколько уровней кеширования и т.д.
Может, кстати, не слишком много. Например, похоже не позволяет:
— статику ( но вроде можно эмулировать. Судя по опубликованным цифрам скорости будет хватать.)
— восстановление дисков, т.к. встретил упоминание в доках, что предполагается запуск ФС поверх рейд-5
Также потребует дофигищи работы и серьезного иследования.
В результате кстати ничего не выбрали, т.к. оказалось реально невостребованным по разным причинам.
Тестировали ли Вы с Selenium «сложные» приложения-сайты? «Сложность» — это, например, кроссдоменная аутентификация, множество внешних источников на странице, сложная и частоизменяемая логика работы?
Если да, то расскажите впечатления.
Текущая версия I18N-0.8.6 (http://pear.php.net/package/I18N) поддерживает меньше языков чем нужно + я к сожалению вообще не нашёл в нем возможности по выводу множественных форм. Вы его имели ввиду? Или я плохо смотрел?
Я подумаю над Вашим вариантом, т.к. потенциально он позволит отказаться от знания алгоритма переводчиком. Больше значительных преимуществ для проекта я не вижу.
То есть интерфейс перевода знал (либо это было описано в файле) кол-во форм для конкретного языка? Или позволял ввести необходимое кол-во вариантов фраз?
А каким образом переводчик понимал что именно эту фразу нужно перевести в нескольких вариантах, а соседнюю фразу нужно просто перевести — варианты множественных форм выделялись или редактировались отдельно?
Кстати, нет ли ссылки на программу или веб-интерфейс для переводчика? Хотелось бы посмотреть в живую.
Использование максимального кол-ва языковых «ключей» для всех языков продиктовано необходимостью поддержки языков в актуальном состоянии.
Процесс перевода в проекте выглядит следующим образом:
* фраза добавляется в английский и русский, так как разработчики знают эти два языка.
* запускается утилита, добавляющая те же самые фразы во все остальные языки (например, в арабский добавляется копия фраз из английского)
* переводчики через публичный интерфейс редактируют ещё не переведённые фразы, используя какой-нибудь язык в качестве «источника»
Если количество вариантов фразы в разных языках будет разным, то необходимо усложнять утилиту и интерфейс для переводчиков.
При этом в проекте используются PHP accelerator, так что потери производительности из-за лишних ключей достаточно малы.
Естественно, в случае другого процесса перевода такое может и не понадобиться.
Хотя за год многое уже могло измениться.
В результате кстати ничего не выбрали, т.к. оказалось реально невостребованным по разным причинам.
Если да, то расскажите впечатления.
Я подумаю над Вашим вариантом, т.к. потенциально он позволит отказаться от знания алгоритма переводчиком. Больше значительных преимуществ для проекта я не вижу.
Спасибо за информацию.
А каким образом переводчик понимал что именно эту фразу нужно перевести в нескольких вариантах, а соседнюю фразу нужно просто перевести — варианты множественных форм выделялись или редактировались отдельно?
Кстати, нет ли ссылки на программу или веб-интерфейс для переводчика? Хотелось бы посмотреть в живую.
Я правильно понимаю, что в Ваших инструментах и интерфейсах редактирования Вы смогли уйти от данной проблемы?
Могли бы Вы привести пример такого или другого интерфейса для перевода, который удобнее по Вашему мнению и лишён описанных недостатков?
Процесс перевода в проекте выглядит следующим образом:
* фраза добавляется в английский и русский, так как разработчики знают эти два языка.
* запускается утилита, добавляющая те же самые фразы во все остальные языки (например, в арабский добавляется копия фраз из английского)
* переводчики через публичный интерфейс редактируют ещё не переведённые фразы, используя какой-нибудь язык в качестве «источника»
Если количество вариантов фразы в разных языках будет разным, то необходимо усложнять утилиту и интерфейс для переводчиков.
При этом в проекте используются PHP accelerator, так что потери производительности из-за лишних ключей достаточно малы.
Естественно, в случае другого процесса перевода такое может и не понадобиться.
Надеюсь, ответил на Ваш вопрос.