1. Унификацию: прийти к единому формату (websocketphp, modnodejs или что-то еще)
Не согласен. websoketphp и прочее — это только транспорт. Другое дело унификация и документирование формата передаваемых данных (как я в статье описал пример). Не важно чем вы передадите эти данные, главное чтобы формат был верным. Вообще все это делается так, чтобы принимать данные не только от MODX, но и в перспективе и от других систем.
2. Обрастанию для него готовых под-модулей и
Эта технология тоже боле менее освоена. В случае с тем же компонентом node.social: есть публичный клиент node.social-client, а есть пока не опубликованный node.social-server (будет позже опубликован). А есть сам node.social (так же пока не опубликованный), который себе устанавливает сразу оба этих модуля. Подключение любого установленного модуля выполняется через var module = require('module_name'); Это и позволит легко обрастать совместимыми компонентами.
3. Удобное включение node.js и мониторинг его состояния со стороны хостинга (modhost).
Спасибо, Максим. Хороший wish-list. Многое из этого мы уже мыслили, но не было оформлено в такой полный список. Сохраню себе в закладки, буду на него ориентироваться тоже.
UPD: Ясное дело, что это все не привычно и не обычно. Складывается следующая ситуация: вот недавний топик, вызвавший кучу положительных отзывов (в том числе и от меня). Там все ясно и понятно, есть четкая направленность и всем понятно что с этим делать (кстати, и никто не сказал, что слишком узкоспецифична (заточка конкретно под уведомления о заказах)). А тут возможности гораздо шире, и это, видимо, и отправляет в ступор (не ясно за что хвататься). ОК. Давайте я скажу, что в рамках этой системы можно получать уведомления о заказах не только внутри админки конкретного отдельного магазина, а вообще со всех магазинов? Так будет понятней? Будет интересней?
Максим, для этого этот топик здесь и висит, чтобы народ высказал свои идеи и мы вместе вывели это из разряда «слишком узкой специализации». Ведь здесь нет ограничений. Это полноценный веб-сервер на node.js, можно сделать кучу отдельных страниц под разные интерфейсы, подцепить базу данных, реализовать разграничение прав пользователей и т.д. и т.п.
Не исключено. Понятно дело, что не так подробно и объемно, как в яндекс-метрике, но все же. А почему нет? У нас есть опыт интеграции с piwik, есть не один год работы с метрикой и гугл-аналитикой (тот же текущий монитор делался, глядя на него), и есть у нас маркетолог, который точно скажет какие метрики в первую очередь надо вычленять, и клиенты со своими отделами продаж, где мы сможем на практике обкатать все это. В общем, планы на самом деле совсем не маленькие, и технологии типа node.js и npm специально исследовались под то, чтобы держать хороший нагрузки, обеспечить легкость в установке/обновлении и очень активно развиваться за счет доступа к гораздо более широкому спектру готовых решений (нежели в рамках одного только MODX).
Затем, чтобы сообщить ноде, что был создан новый MODX-объект (тот же заказ). Не стоит же для этого создавать API на стороне MODX-а и давать ноде «присасываться» к MODX-у, чтобы узнавать что там происходит.
Это похоже на Event-API в слэке. Есть два режима:
1. Отправить самостоятельно запрос MODX-у и «узнать» что у него там нового есть.
2. MODX сам шлет запрос ноде и говорит «у меня такие-то новости».
Но вот браузерному клиенту конектиться к ноде через php действительно не за чем, это можно делать напрямую. Максимум, в ноду можно прописать авторизацию или проверку доступа пользователя через запрос к MODX-у.
Блин, хоть кто-нибудь бы сказал что-то или спросил. Интересная же технология. Вся прелесть в том, что интерфейсы можно допиливать как угодно, используется очень мощная либа chart.js.
Или ладно, даже если все это сложно пилить и т.п., наверняка же есть какие-то идеи-пожелания, можно высказаться. Мы, к примеру, мыслим сервис на базе этого сделать (мониторинг + онлайн-консультант + управление всеми заказами + многое другое). Может кому нужны какие-то особые данные статистики со своего сайта, но не знает как это все запилить, можно высказать идеи, мы подумаем на счет того чтобы их реализовать.
Приведи пример где не только тебе будет полезно послать запрос из модкс куда-либо, и я начну над ним думать.
Очень просто: у меня несколько магазинов на совершенно разных доменах. Я хочу получать и обрабатывать заказы со всех этих магазинов в одном месте. Все эти магазины отправляют мне запросы на один нод-сервер (и на разных доменах). При этом, на сайтах этих могут уходить запросы на другие нод-сервера (к примеру, как вот этот сервер статистики). То есть мне нельзя на одном отдельном сайте привязаться к какому-то одному хосту и порту под все случаи жизни, и я не хочу на уровне отдельно выделенной ноды конкретно под этот сайт пересылать на другие собирающие нод-сервера.
А вообще по таким вот обсуждения я уже предлагал тебе общаться в слаке да бы не захломлять тему.
Не захламлять тему чем? Информацией по твоему же компоненту? Не задавай сейчас ответных вопросов, я не буду на них отвечать, диалог закончится.
Понимаешь в чем разница? Я могу своими средствами отправить запрос на твой адрес, а ты не можешь на мой. Или даже сказать так: я могу отправить на любой адрес, включая твой, а ты сможешь слать запросы только на свой адрес, а на чужие не сможешь. Понимаешь о чем я? Зачем завязываться только на себе? В этом и проблема большинства компонентов — они затачиваются под себя, не думая о универсальности.
Ок, не вопрос, не буду больше тебе надоедать. Ты хочешь делать свой продукт лучше, но не слушать никого. Только зачем это писать?
Жду пулл реквестов и пожеланий, надеюсь связка кому-нибудь да понадобиться.
Я попробовал, и дал комментарии/пожелания. Может ты не их хотел слышать, а «комплименты»? Комплименты приятны, конечно, но не делают продукт лучше.
Зачем? Есть методы типа $modx->getManager()->createObjectContainer(), $modx->getManager()->addField(), $modx->getManager()->addIndex(), $modx->getManager()->alterField() и т.п.
1) значит у тебя по этому адресу нет ответа, следовательно не правильный хост\порт
Порт и хост верный. Но модуль шлет запрос не на корень хоста, а на адрес /socket.io/?EIO=2… (см п. 2) У меня обработка этого адреса не прописана, поэтому 404-ая.
2) моя связка на сокет.io, на ноде вылавливаются эвенты через сокетио а не «голая нода»
Ну а зачем на это завязываться? Дай метод типа IoSend($data), который сформирует данные нужные (и адрес нужный), и отправит через голый send($address, $data), который умеет слать данные в любом формате на любой адрес.
3) JSON.parse(data)
Думаешь, я не знаю этого метода? :) Но твой модуль шлет запросы типа 42["/", "{\«type\»:\«sdfsdf\»}"]. Попробуй в той же консоли выполнить print_r(json_decode('42["/", "{\«type\»:\«sdfsdf\»}"]',1)). Что он тебе даст? Ничего. Потому что 42 в начале бьет все. Надо просто '["/", "{\«type\»:\«sdfsdf\»}"]'.
Я не могу предположить зачем слать запросы на кучу разных серверов, когда будет использоваться один.
А почему не использовать несколько серверов? Зачем вообще под это затачиваться. Сейчас это выглядит как телефон, в который зашили непереустанавливаемое ПО и который звонить может только на один определенный номер.
Вот посмотри сюда: stat.modmonitor.ru/
Мне слать данные нужно туда с разных сайтов. Вот через твой модуль не получилось этого сделать. Через мой получилось.
Никита, попробовал я твой компонент. Небольшой фидбэк. Сразу уточню, что в первую очередь интересовала возможность выполнения запросов на какие-то свои собственные ws-ресурсы, а не только на специально выделенный под этот компонент адрес.
1. Из админки постоянно идет долбежка на несуществующий адрес. joxi.ru/RmzXOWVu0RGQbA
2. Зачем ты жестко прописал адрес куда отправлять запросы? Пришлось хардом заменить на нужный адрес.
3. Зачем ты вот здесь пишешь в начале 42? Я на своем сервере ловлю ошибку разбора JSON-строки.
Вот если все это поправить, то можно использовать его для запросов на произвольный ws-сервер по протоколу ws://. А вот wss:// судя по всему нельзя?
Себе я собрал простенький компонент websoketphp, вот он без проблем отправляет запросы на такие сервера ( в том числе и по ssl). Используется выше указанная библиотека websoket-php. В рамках пакета вызов выполняется просто.
Я вообще еще не приступил к выполнению одной особенной задачи, но скоро приступлю. Суть в том, что у нас много объектов и не только по России. Обычно загружают весь пулл данных, просто визуально пользователь видит то, что в рамках его масштаба видно. Я же хочу сделать так, чтобы с сервера подгружались данные только для видимой географической области + пара шагов масштаба. Тогда объем передаваемых данных будет значительно меньше, а отрисовка оперативней.
Эта технология тоже боле менее освоена. В случае с тем же компонентом node.social: есть публичный клиент node.social-client, а есть пока не опубликованный node.social-server (будет позже опубликован). А есть сам node.social (так же пока не опубликованный), который себе устанавливает сразу оба этих модуля. Подключение любого установленного модуля выполняется через var module = require('module_name'); Это и позволит легко обрастать совместимыми компонентами.
Вот это, думаю, вообще не проблема.
Это похоже на Event-API в слэке. Есть два режима:
1. Отправить самостоятельно запрос MODX-у и «узнать» что у него там нового есть.
2. MODX сам шлет запрос ноде и говорит «у меня такие-то новости».
Но вот браузерному клиенту конектиться к ноде через php действительно не за чем, это можно делать напрямую. Максимум, в ноду можно прописать авторизацию или проверку доступа пользователя через запрос к MODX-у.
Или ладно, даже если все это сложно пилить и т.п., наверняка же есть какие-то идеи-пожелания, можно высказаться. Мы, к примеру, мыслим сервис на базе этого сделать (мониторинг + онлайн-консультант + управление всеми заказами + многое другое). Может кому нужны какие-то особые данные статистики со своего сайта, но не знает как это все запилить, можно высказать идеи, мы подумаем на счет того чтобы их реализовать.
Сигнал есть. Теперь можно зайти в админку и проанализировать что там вообще было. Это какой-то commoncrawl-паук.
Перепроверю что там не так на сайте.
Не захламлять тему чем? Информацией по твоему же компоненту? Не задавай сейчас ответных вопросов, я не буду на них отвечать, диалог закончится.
Ок, не вопрос, не буду больше тебе надоедать. Ты хочешь делать свой продукт лучше, но не слушать никого. Только зачем это писать? Я попробовал, и дал комментарии/пожелания. Может ты не их хотел слышать, а «комплименты»? Комплименты приятны, конечно, но не делают продукт лучше.
Ну а зачем на это завязываться? Дай метод типа IoSend($data), который сформирует данные нужные (и адрес нужный), и отправит через голый send($address, $data), который умеет слать данные в любом формате на любой адрес.
Думаешь, я не знаю этого метода? :) Но твой модуль шлет запросы типа 42["/", "{\«type\»:\«sdfsdf\»}"]. Попробуй в той же консоли выполнить print_r(json_decode('42["/", "{\«type\»:\«sdfsdf\»}"]',1)). Что он тебе даст? Ничего. Потому что 42 в начале бьет все. Надо просто '["/", "{\«type\»:\«sdfsdf\»}"]'.
А почему не использовать несколько серверов? Зачем вообще под это затачиваться. Сейчас это выглядит как телефон, в который зашили непереустанавливаемое ПО и который звонить может только на один определенный номер.
Вот посмотри сюда: stat.modmonitor.ru/
Мне слать данные нужно туда с разных сайтов. Вот через твой модуль не получилось этого сделать. Через мой получилось.
1. Из админки постоянно идет долбежка на несуществующий адрес.
joxi.ru/RmzXOWVu0RGQbA
2. Зачем ты жестко прописал адрес куда отправлять запросы? Пришлось хардом заменить на нужный адрес.
3. Зачем ты вот здесь пишешь в начале 42? Я на своем сервере ловлю ошибку разбора JSON-строки.
Вот если все это поправить, то можно использовать его для запросов на произвольный ws-сервер по протоколу ws://. А вот wss:// судя по всему нельзя?
Себе я собрал простенький компонент websoketphp, вот он без проблем отправляет запросы на такие сервера ( в том числе и по ssl). Используется выше указанная библиотека websoket-php. В рамках пакета вызов выполняется просто.
Сейчас выложу его тоже в модстор, будет бесплатным. Он понадобится под анонс другого моего компонента.
Мне как раз на одном проекте нужна гугл-карта с кластеризацией. От яндекс-карт думаю отказаться.