ваш оптимизм конечно похвален, но я бы сказал что вы заявляете пока еще трудноподъемные для вашей технологии вещи.сейчас будет много критики. я не столько хочу чутька сбить ваш оптимизм, сколько дать вам понять какие у вашей технологии сейчас я вижу проблемы. возможно я не прав, и вы меня переубедите, или примерами докажете, что я не прав.
допускаю, что я сейчас попросту не понимаю как вы организуете серверные скрипты, плохо понимаю, что в ваших терминах является контроллером (уж не MVC ли? но тогда где модель?...).. но если я этого не понимаю - тогда у меня вопрос: а где доки которые дают мне как архитеткору или разработчику "модель вашего приложения" ? тех 2-х рисунков что есть в текщих манах - не достаточно. примеры - можете их сделать? в описанных на рисунках терминах разложить несколько примеров простого взаимодйствия - простой, средний (см ниже лифлет) , сложный ...
В общем делайте мануалы и демки? но это спойлер - см про это в конце.
Теперь про проблемы которые я вижу:
_________________
во первых. ты часть проблем, что вытекает из простоты протокола.
Сейчас это, имхо, как proof-of-cоncept. Протокол не предполагает передачу проивольных данных между клиентом и сервером, генерацию событий программно, у клиента нет js-api, нет механизмов взаимодействия сервера с находящимся на клиенте js (например как вы хотите добалять на leaflet-карту новые объекты?). вы похоже не очень то предрасположены к тесной интеграции с js ? да есть метод вызова произвольного js - но там же стоит пометка "Рекомендуется минимизировать использование"?
Вопрос: как вы, например, собираетесь обрабатывать сдвига карты в leaflet - что бы запростиь у сервера объекты для новой области отображения? ведь у вас нет ни js-api в клиенте, ни механизма генерации событий программно, ни передачи дополниетльных, динамически генерируемых данных с событиями отсылаемыми на сервер.
Будете делать это _не_ через PUSA? тогда прогнозирую нежелание разработчиков пользовать клиент pusa на стороне клиента. Примерно так же как мы не хотели видеть JSF потому что с "его клиентом" было очень проблемно интегрироваться - вызвать метод какого-то бина на сервере, когда ты находишься в js-коде - это сплошные костыли.
_________________
во вторых. часть проблем - из выбранного языка реализации и механизма взаимодействия.
Простите, но вы сказали что применения вашего протокола - больше чем то что описано на странице hrud - но заявлять про statefull приложение когда в php банально нет управления процессами и межпроцессного взаимодействия... это имхо странно.
Сложное корпоративное приложение - оно живет на сервере постоянно, а не пока генерятся странички. Хотите совет? понимаю, это нагло, но если хотите развивать вашу спеку далее - переходите на Java, или C#. именно там вы отхватите кучу всего, что надо добавлять в ваш протокол. заодно поймете как перестроить структуру и внутреннюю логику вашего решения тоже - если потребуется.
Далее - как говорить про сферу применения - "statefull приложения" когда у вас сервер не знает состояния клиентских узлов или хотя бы модели клиентской страницы? имхо - это как-то странно.
И пока вы сидите на php - вы не сможете организовать без костылей хранение состояния клиента на севере в памяти (хотя возможно мои знания про php устарели и вы знаете как это сделать изящно... но я вот думаю что нет таких вариантов с пхп ).
_________________
И если вы создавали Pusa как спооб избавиться от JS - и это, имхо, "не прокатит".
У вас не хватит возможностей. Банально - разберитесь как реализовывать работу с Leaflet - например. Сейчас у вас не хватит быстродействия - куча ajax запросов на каждый чих который надо обрабатывать на клиенте - этот шквал может сожрать быстродействие и погребет любые попытки сделать что-то более-менее сложное. т.е. я к чему - от js вы не откажетесь, примите это, и научитесть жить с ним.
_________________
И ВАЖНО: поймите вашу нишу. сейчас вы заявляете о слишком большой области, что бы верить вам наслово - это как с новыми языками - создатели всегда начинают свои поделия пихать куда ни попадя. Вот примерно как вы озвучили "непоймикакую" широкую нишу применения.
Понимаю - вам кажется что у вас в руках Бруксовская "серебрянная пуля"... но имхо, важно понять, что эту пулю надо "приземлить" как можно быстрее и найти вашу нишу. Пока не наломали дров, пока интерес публики не кончился... Но это - только имхо . стратегия развития вашего продукта - ваша стратегия.
Для сравнения: hrud создавался не из соображения отказа от js - хотя это почти и получилось. hrud создавался для целей локализации бизнес-логики на серверной стороне. Именно бизнес-логики, с оставлением логики отображения на клиенте (т.е. например вопросы тесной интеграции с js - которые у вас не решены или числятся как "жежательно минимизировать" - там - заложены на уровне архитектуры и являются обычным штатным механизмом).
Его область - это та область, где технологии построения приложений на типичных спрингово-ангулярных связках слишком тяжеловесны, медлительны в разработке и модификации, когда куча микросервисов начинает неуправляемо "разваливаться" и ею становаится трудно управлять, когда js-приложение настолько большое что даже грузится минуту, а переплетение операций такое, что у вас бизнес-логика начинает "просачиваться" на клинета через сотню циклов рефакторинга (и в итоге через F12 ты можешь начать делать операции не так как это допускаетс приложение....) - и вот именно это ниша - та самая в которой hrud более мнее способен конкурировать со "спрингво-ангуляровой попсой" - потому что позволяет эти проблемы решить и прделагает процесс разработки, который не приводит к подобным эффектам ))
потому у него и написано в области применения - "не для массовых-публичных сайтов".
Вы же, как я понимаю, хотите переенсти всю логику на сервер просто потмоу что "не хочется в JS"? И предложить решение всем и везде - в массовом вебе... имхо - не выйдет. "в чем цимес?" - вам это надо будет объяснить. И чем ваш вариант "лучше перегенерации страницы как это делается например на _этом_ форуме"? (см ниже секцию про "нишу")
И проблема даже не потому что "у нас уже есть куча ангулярщиков". Заявленное в полном виде (перенос всей логики на сервер) можно будет сделать только через полный аналог rdp- или x- клиента в браузере, и как следствие - полностью перестроить логику приложения на сервере. И придумать кучу компонент под себя (напрмер карты?). А у вас еще и в добавок - нет модели страницы клиента на сервере...
+ массовый веб не поймет увеличения нагрузки на сервер при потенциально неограниченном числе клиентов. Попытки вынести на клиента бОльшую часть логики - и появление тяжелых js-клиентов (реакт-ангулярных) - вот это всё ужасное-и-противное что вы тоже наблюдаете - не от простой же это жизни появилось? Нет. а с целью как раз _разгрузить_ сервер. А вы предлагаете его как раз наоборот - нагрузить. И массовый веб вас спросит - "а зачем?!". и как я понимаю по комментам - уже спрашивает.
А корпоративный сектор "тяжелых" приложений для вас - с php - практически закрыт.
не с php соваться в "тяжелый интерпрайз". ну вот серьезно.
(*) и да предвижу вопросы - сразу скажу : вконтактик - это не "тяжелое интерпрайз приложение". это "одностраничник с _примитивной_ бизнес логикой в 3 клика".
И.... вот как-то для начала так.
Надеюсь я вас не сильно "приложил" ?
Если сможете выдержать - "добро пожаловать в коллектив" ))
_________________
Возможно я не прав во всем выше, и вы сейчас в ответ на всё что я рассказал - найдете кучу "элегантных" решений или придумаете что то вообще супер крутое...
Но почему бы не начать с того, что бы сделать ... демки ? Демки и примеры. Несколько кейсов которые показывают чем ваше решение облегчает разработку приложений.
Потому что вы - создатель. У вас есть идея. А я - токсичный комментатор который не понимает как использовать то что вы предлагаете.
Покажите вашу идею! воплотите! я же пока могу только гадать и вспоминать мои шишки.
_________________
Не знаю что предложить... - давайте скажем ... для начала
1) карту, с отображением только объектов, которые только в отображаемой области. с динамическйо подгрузкой данных с сервера через pusa;
2) выполнение на сервере какого-то длительного расчета с отображением прогресс-бара;
и всё это - на технологии вашего протокола и вашего клиента.
Без много-сот-строчного js-кода и "классических ajaх-запросов" вне вашего клиента.
Всё общение с сервером - только через ваш клиент (ведь перестройка UI - в вашей идеологии - только через него и производится?(троллинг)
Еще покажите как будет вести себя ваше приложение когда будут открыты 2 вкладки в одном браузере - и на ниж будут "нажиматься разные кнопки".
И уже потом можно будет разговаривать более предметно.
Предметно, и дальше - там еще есть пучок проблем на этом пути, но как первый шаг - я бы предложил вам решить описанные ваше кейсы.
справитесь?
