MajorDoMo

LutsenkoDenis писал(а):b]Про гитхаб...[/b]
Обычно как обстоит дело... берешь исходники проекта и они содержат все. Т.е. из исходников можно сделать дистрибутив.
Если брать виндовую версию дистриба мажордома, то из исходников дистриб не соберешь. Т.е. на гитхабе лежит не всё.

И вот как и я про эту проблему. Такого не должно быть.

Пока могу обещать что мои изменения (исходника) будут содержать все что нужно для сборки и запуска majordomo.

igk1972 писал(а):Но для Majordome (по моему мнению) вполне можно (и нужно) использовать встроенный web-сервер в самом php (5.4 и выше).

А что это даст? Простыми словами, плз, так как я "чайник"

Amarok писал(а):

igk1972 писал(а):Но для Majordome (по моему мнению) вполне можно (и нужно) использовать встроенный web-сервер в самом php (5.4 и выше).

А что это даст? Простыми словами, плз, так как я "чайник"

Не сочтите за неуважение, но нужно больше знаний/опыта для понимания некоторых внутренних аспектов веб-проектов, и связанных с ними проблем потребления ресурсов.

Попробую пояснить.
В Majordomo (в текущем версии 0.9 и раздаваемых инсталляциях) использует самая старая и ресурсоёмкая связка Linux/Windows + Apache + PHP. То есть php работает в виде модуля apache.
Хотя 95% всей работы приходится только на php - в циклах, и в множественных get/ajax запросах при активном терминале (это обновления данных в блоках и прочее). На малую серию запросов/операций (даже минимальную) веб-сервер apache порождает отдельный процесс с php внутри + загружаемый код majordomo.
Это ведет к трате ресурсов компьютера:
- множественных расход памяти на процессы apache;
- трата времени на запуск процессов и загрузку кода;
- трата времени на постоянные пере-соединения к бд;

Многие могу сказать: есть же nginx или lighttpd. Плюс переход на выполнение php в службе/демоне php-fpm.
Да, применение такого улучшает ситуацию потребления рессурсов.

Но напомню что в Majordomo достаточно мало загружаемый статичных файлов (js/css/jpg/png/woff). И так же можно уменьшить кол-во их загрузок. С нами вполне справиться внутренний веб-сервер в php (5.4 и выше).
Поэтому применение отдельной службы/демона веб-сервера считаю излишним.

Кстати, возможно стоит рассмотреть вариант использования бд sqlite3 в качестве хранилища данных. Это позволит отказатся еще и от mysql (c его потребностями к памяти и процессору). Сделать выбор на этапе инсталляции и(ли) выбора инсталлятора.

Таким образом Majordomo получиться более быстрым, более монолитным, более управляемым, менее ресурсоёмким.

igk1972 писал(а):

Amarok писал(а):

igk1972 писал(а):Но для Majordome (по моему мнению) вполне можно (и нужно) использовать встроенный web-сервер в самом php (5.4 и выше).

А что это даст? Простыми словами, плз, так как я "чайник"

Не сочтите за неуважение, но нужно больше знаний/опыта для понимания некоторых внутренних аспектов веб-проектов, и связанных с ними проблем потребления ресурсов.

Отвечаю шепотом: "В прошлый раз вы помните? Все приходит с опытом." (с)

igk1972 писал(а):Но напомню что в Majordomo достаточно мало загружаемый статичных файлов (js/css/jpg/png/woff). И так же можно уменьшить кол-во их загрузок. С нами вполне справиться внутренний веб-сервер в php (5.4 и выше)

Как это можно сделать?

Amarok писал(а):

igk1972 писал(а):Но напомню что в Majordomo достаточно мало загружаемый статичных файлов (js/css/jpg/png/woff). И так же можно уменьшить кол-во их загрузок. С нами вполне справиться внутренний веб-сервер в php (5.4 и выше)

Как это можно сделать?

В данный день и час - никак )))

Но можно просто подождать публикации моих изменений Majordomo.
Изменения касаются всего того о чем я писал в этой ветке обсуждения.

В данный момент у меня готово:
- запуск и работа только в веб-сервере php (htaccess тоже обрабатывается).
- исправлена логическая проблема при ошибке чтения бд и попытки записать туда же отчет об ошибке.
- наведен порядок с папками в корне проекта, организованы папки vendor, assets, некоторые переименованы, естественно в коде внесены нужные исправления.
- удалены вызовы файлов которых нет (например codemirror css.js, /php.js).
- все веб-выдаваемое теперь только doctype html (html5).
- стандартизированы загрузки css и js.

В ближайщих планах:
- четкий, понятный ии настраиваемый routing (сейчас этим частично занимается файл nf.php, но в нем все hardcode).
- единая точка запуска для веб - index.php - это позволит унифицировать общую архитектуру и логику.
- устраненние логической путаницы в наименовании файлов в папке lib - файлы *.class.php не должны содержать простые функции, а просто иметь иное название.
- автозагрузчик классов по необходимости их использования, не так как сейчас.
- веб-инсталлятор с проверкой всего того что необходимо нормальной работе Majordomo.
- разделение текущего mysql.class.php на файл database.php (sql-функции) и mysq.class.php (работа с mysql).
- создание sqlite.class.php.
- пересмотр расположений файлов модулей, их группировка в папке самого модуля.
- отказ от jquery-mobile, так как bootstrap3 вполне охватывает все что нужно, даже для мобильных устройств.
- переход на систему миграции в работе с бд.

В планах:
- переход на json обновление данный по websockets.
- переход на систему git для обновлений.

Естественно при публикации изменений, будет дана инструкция, и надо будет проводить массовые тесты и прочее.

Очень любопытно. Встречные вопросы по теме:
1. Когда ждать это?
2. Как будет проходить обновление старых систем? Смогу я обновить свою вин-версию?

Amarok писал(а):Очень любопытно. Встречные вопросы по теме:
1. Когда ждать это?
2. Как будет проходить обновление старых систем? Смогу я обновить свою вин-версию?

1) Пробная версия в моих планах к концу мая. Если все будет хорошо.

2) До обновления старых версий еще далеко. Я не сторонник быстрых релизов при таких изменениях.
По всей видимости, для перехода со старых версий, будет написан скрипт. Его надо будет детально тестировать.

У многих тут уже наработки свои большие, поэтому однозначно нужен качественный и оттестированный скрипт миграции.

slgeo писал(а):У многих тут уже наработки свои большие, поэтому однозначно нужен качественный и оттестированный скрипт миграции.

Никто ведь не торопит насильно обновлять системы в production. Оттестируем.

Как будет проходить обновление?