Комментарии 15
Уважаемый автор, Вам не кажется, что одной страницы документации маловато будет? Каким бы гениальным не был продукт — трудно будет собрать аудиторию без подробной документации.
В Wiki на Github'е почти пусто…
В Wiki на Github'е почти пусто…
До текущего момента делать документацию было бессмысленно, структура и архитектура менялась очень динамично и документация бы мгновенно устаревала. Поэтому, в качестве бета-тестеров в течении последнего года выступали мои друзья и команда разработки, которые испытывали все неудобства быстро развивающегося продукта на себе, хотя были и совершенно незнакомые программисты, очень смелые, нужно думать, ребята. Каждые 5-10 минорных версий совместимость обрывалась и я старался сгладить эти проблемы, помогая в быстром изменении проектов и ведя подробные логи изменений, которые стали хорошей заменой документации на время активной разработки. Перед каждым обновлением версии нужно было заглянуть в лог изменений, где были подсказки по конвертации, иногда хватало сделать замену строки, а иногда блоки кода переносились в другое место. В любом случае, сейчас структура приложений уже почти закреплена и, в ближайшее время, к выходу версии 0.2, будет подробная документация.
НЛО прилетело и опубликовало эту надпись здесь
Надеюсь продолжение не задержится.
Пробовал экспериментировать с node.js но оттолкнуло то что начинать приходится, образно говоря, с «выплавки руды».
Пробовал экспериментировать с node.js но оттолкнуло то что начинать приходится, образно говоря, с «выплавки руды».
Почему вы не используете jsdoc?
С удовольствием бы использовал и генерил бы доки из кода, но из-за особенностей структуры ядра IAS, jsdoc не всегда понимает к чему относятся методы, они часто попадают в область видимости через нетривиальные механизмы, через фабрику прототипов, через примеси и замыкания, а некоторые даже из контекста песочницы v8, и jsdoc запутывается. Кто-то уже пробовал прикрутить, но сталкивался с проблемами, может не полностью разобрался и это все же как-то можно устроить.
jsdoc — это же просто формат записи комментариев. Не обязательно использовать какой-то парсер/генератор документации, чтобы начать писать комментарии в общепринятом формате.
Если мы научимся из него доки генерить, то да, а так он мне по синтаксису не очень нравится, возможно другой парсер или настройки/модификации какие помогут.
Если честно — никому не нужны доки по jsdoc и прочие *doc. Но они таки нужны для IDE. В правильных IDE дается правильный автокомплит, при наличии *doc.
После прочтения возникло несколько вопросов:
1. Поддерживается ли возврат промиса из обработчика, вместо использования
2. Как внутри обработчика осуществляется подгрузка стандартных имён (
3. Поддерживается ли
4. Что подразумевается под шиной событий в части про WS? Означает ли она наличие механизмов, которые позволят сделать сокетное взаимодействие так, что можно выкинуть socket.io?
1. Поддерживается ли возврат промиса из обработчика, вместо использования
callback
?2. Как внутри обработчика осуществляется подгрузка стандартных имён (
setTimeout
) и имён ноды (request
), а также их запрет?3. Поддерживается ли
.htm
, как формат, наряду с .html
?4. Что подразумевается под шиной событий в части про WS? Означает ли она наличие механизмов, которые позволят сделать сокетное взаимодействие так, что можно выкинуть socket.io?
- Нет, только callback
- У каждого приложения есть
/config/sandbox.js
, в нем параметрglobal
, он по умолчанию закомментирован, это значит, что нужно пробрасывать в global приложения все стандартные имена. Но если его раскомментировать и удалить из списка require, например, то он не будет виден в приложении. - Да, все расширения, кроме прямо заданных (.json, .jsonp...) обрабатываются как html, т.е. .htm будет работать как .html
- Точно, в приложении, что идет как пример, работают два варианта получения сообщений с сервера, через WebSockets и SSE, это без socket.io
По поводу (1), я спрашиваю потому, что если поддержка промисов будет, то обработчики будут очень гладко интегрироваться с существующим кодом на промисах. Причём и в плане возврата данных и в плане обработки ошибок. Сейчас, естественно, можно привязать
Так или иначе, меня очень заинтересовал impress, и я рад, что всё это развивается.
По поводу (4) это очень круто, мне не нравятся существующие решения для сокетов. Вот socket.io, уже упомянутый, акцентирует внимание на событиях. С моей точки зрения это неверно, а надо акцентировать внимание на протоколах. Ведь мы используем события просто как не самую удачную модель над некоторым протоколом нашего приложения. Я считаю в сокетной либе кроме одиночных событий и broadcast-сообщений должны быть реквесты (также как это делается в HTTP, необходимость в реквестах никуда не исчезает).
Я даже задумываюсь над написанием либы, которая в качестве отправной точки постулирует два пункта: 1. либа инициализируется объектом-протоколом, 2. можно делать реквесты, которые мультиплексируются в сокете.
callback
на then
и на треть проблему решить, но нативная интеграция с промисами во много крат лучше. Также это двигает всю систему в сторону поддержки корутин (прям как в Koa).Так или иначе, меня очень заинтересовал impress, и я рад, что всё это развивается.
По поводу (4) это очень круто, мне не нравятся существующие решения для сокетов. Вот socket.io, уже упомянутый, акцентирует внимание на событиях. С моей точки зрения это неверно, а надо акцентировать внимание на протоколах. Ведь мы используем события просто как не самую удачную модель над некоторым протоколом нашего приложения. Я считаю в сокетной либе кроме одиночных событий и broadcast-сообщений должны быть реквесты (также как это делается в HTTP, необходимость в реквестах никуда не исчезает).
Я даже задумываюсь над написанием либы, которая в качестве отправной точки постулирует два пункта: 1. либа инициализируется объектом-протоколом, 2. можно делать реквесты, которые мультиплексируются в сокете.
По поводу промисов, я планирую их реализацию в 0.3 уже, потому, что это изменит многие вещи, а хотелось бы ответвить уже 0.2 и держать ее в стабильном виде для ежедневной разработки. Быстрое развитие — это конечно хорошо, но в 0.1 все страдали от того, что каждые 10-15 минорных версий обязательно что-то критическое менялось и нужно было рефакторить приложения, а отказаться от обновлений тоже нельзя, потому, что в них и ошибки же закрываются.
Одна из основных фич в том, что на одном порту можно сделать все, мультиплексируется по урлам, на одном урле SSE, на другом WebSocket, и тех же событийных каналов много можно одновременно на разных урлах держать, ну и на том же порту API и стриминг и статика и контент и все остальное. На ноде же обычно много портов открыто для каждой задачи специфический порт, и так выходит, что даже для не очень сложных приложений уже 2-5 портов открыто. А потом какой-то маршрутизатор рубит все кроме 80 или CORS не пропускает или еще что-то, в общем мультиплексирование в ноде не развито совсем.
Одна из основных фич в том, что на одном порту можно сделать все, мультиплексируется по урлам, на одном урле SSE, на другом WebSocket, и тех же событийных каналов много можно одновременно на разных урлах держать, ну и на том же порту API и стриминг и статика и контент и все остальное. На ноде же обычно много портов открыто для каждой задачи специфический порт, и так выходит, что даже для не очень сложных приложений уже 2-5 портов открыто. А потом какой-то маршрутизатор рубит все кроме 80 или CORS не пропускает или еще что-то, в общем мультиплексирование в ноде не развито совсем.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Impress Application Server простыми словами