Сообщений в теме: 82

[balabollng]

После мозгового штурма проведенного вчера с одним из спецов по OpenWRT, было принято решение, что то, что ОС будет грузиться с внешней флешки, не баг, а фича

 

Что придется в этом плане сделать, так это прошивку, которая будет сама определять наличие чистой флешки и готовить ее под перенос ОС. Чтобы любой "смертный" мог это сделать. Чем и займусь в ближайшее время. 

 

Далее работа с прошивкой будет классической. 

[balabollng]

И так, чего успел добиться:

 

1. Сделал прошивку для MR3020, которая включила в себя все принципиально необходимое для разворачивания системы;

2. Прошивка работает по следующей схеме:

2.1. Прошиваем роутер;

2.2. При входе на роутер по WiFi или Ethernet открывается страница с инструкцией по развертыванию;

2.3. Вставляем флешку, перегружаем роутер;

2.4. Прошивка сама форматирует флешку как нужно и перемещает туда все системные файлы;

2.5. Новая перезагрузка, и теперь роутер грузится с флешки. 

3. Соответственно объем файловой системы ограничен только размером флешки.

4. Если флешку вынуть из роутера, он переходит в состояние п.2.2 Т.е. если вы что-то натворили в системе, можно просто вынуть флешку и получить "нулевую" прошивку.

[balabollng]

Некоторое время не отмечался. Но не беда. Теперь есть, что показать.

 

Создан движок приложений. На структуру и фундаментальный принцип приложений во многом повлиял Android. 

 

Но тут было важно незагоняться. Т. к. все же работает система на JavaScript. 

 

В общем, приближенная структура приложения видится так:

 

 

Самый верхний уровень это системное имя приложение. Оно должно быть уникальным. Много размышлял по теме многоуровневого именования как в Android типа com.market.my. Отказался. Контроль валидности имени будет происходить при публиковании приложения. 

 

activity - тут храним классы на JavaScript реализующие некоторую активность приложения. К примеру код формы. Или код виджета.

res - тут храним все ресурсы приложения. Интересным будет отметить, что ресурсы можно будет размещать как с языковой зависимостью, так и с аппаратной зависимостью. Как в Android. 

res->views - визуализация на html. Т.е. практически простой html. Ничем не ограничивающий возможности разработчика. В принципе, можно в нем обойти всю систему. Но нужно ли?

res->images - картинки. Тут важно подчеркнуть, что картинки будут выдаваться приложению в зависимости от аппартаных возможностей клиента.

values - различного рода значения. Опять подчеркну, что значения могут зависеть от выбранного языка.

 

ну и manifest - тут мы сообщаем системе, что и как наше приложение будет делать. 

 

Пример кода прилоежния main.js

 

 

Пример кода на html main.html

 

 

Если есть люди знакомые с Android, наверное они найдут некоторые общие черты

 

А вот и визуализация, т.е. работающее приложение

 

 

Слева перечень установленных приложений в системе. Пока их всего два Справа область исполнения приложения. 

 

Вот и все  Хоть демонстрация и не великая, но кода написано много

 

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

 

Settings - все настройки.

Applications manager - управление приложениями. 

[balabollng]

И опять пообщаюсь сам с собой

 

Итогом последних выходных стало внедрение класса launcher. И в связи с этим некоторую переработку архитектуры. 

 

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

 

Но я не для функциональности ради этот класс внедрил. Получилось упростить ядро. А это всегда на пользу

 

Ну и с ресурсами разобрался. Для разработка приложений все будет очень просто. В форме он указывает специальный тэг MWRT-VALUE. И этот тег уже сам разбирается в какой локализации приложение функционирует и забирает необходимое значение.

 

В коде выглядит так:

 

 

Структура ресурсов такая:

 

 

Файлы ресурсов:

 

default.json:

 

ru.json:

 

Собственно ключ ресурса "HelloWorld". Система, в зависимости от локализации будет отдавать приложению строку либо "Hello World!" либо "Привет мир!"

[balabollng]

Значит, все хорошо. Но, есть желание, сделать возможность использования CSS подобно тематическим схемам в Android.

 

Сама реализация видится очень простой. Будет локальные CSS которые предполагается описывать так:

 

.localCSS {

width:100%;

}

 

Но, в итоге, все классы этих локальных CSS должны преобразоваться (автоматом, ядром системы) в вид:

 

.myapplication.localCSS {

width:100%;

}

 

Т.е. эти локальные CSS должны будут распространяться только на элементы страницы вложенные в элемент с классом "myapplication". 

 

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

 

 

Проблема в том, что готовый CSS не обернуть так легко еще в один класс. Либо нужно парсить на стороне сервера и выдавать подготовленный CSS, что мне не сильно нравится, т. к. нагружает сервер, либо, как-то реализовывать это дело на клиенте. Но вот - как? Этот вопрос я пока не решил....

 

Может есть идеи?

[avfv]

А как же без идей. <iframe> решит все проблемы. Все равно нет способа надежно слепить в кучу произвольное количество js модулей, независимо написанных разными людьми. К тому же у разработчиков должна быть возможность использовать привычные им подходы и инструменты, иначе вряд ли кто-то будет под это писать.

[balabollng]

Да, iframe как бы решение, но далеко не симпатичное. 

 

Поясню. 

 

1. Я не ставлю перед собой задачу полной изоляции приложений. Т.е. я не хочу ограничивать разработчика в возможностях JavaScript и HTML. Если кому-то очень захочется обойти все предложенные правила, то он может это сделать свободно, на свой страх и риск. Я "рожаю" систему, которая должна облегчать жизнь, а не убивать возможности. Поэтому, жесткая изоляция приложения не имеет смысла. У меня изоляция происходит на логическом уровне. 

2. Приложения, как и в андройд, могут экспортировать (давать возможность пользоваться ими другим приложениям) стили, активити, источники данных и т.д. Т.е. загонять их в iframe противопоказано. Работают они в едином пространстве имен. Т.е. опять, iframe противопоказан, т. к. при его использовании пространство имен будет изолировано, передача данных затруднена. 

3. Я предполагаю, что писать будут не потому, что разработчики смогут пользоваться привычными средствами, хотя таких и будет куча, а потому, что это будет единственная платформа, в которой приложение и железка живет по единым правилам. И ты, ровно так же как обращаешься к соседнему приложению, сможешь обратиться к модулю Arduino, ничего не делая принципиально особого. 

 

Это то, что меня останавливает от использования iframe...

 

Но в варианте со стилями, к сожалению, судя по всему, придется либо придумывать велосипед, либо идти по пути iframe... где разбирать стиль и импортировать в основной контекст уже преобразованным

[avfv]

html и js в принципе корявые технологии, так уж сложилось.

 

Без изоляции приложений все просто-напросто развалится под собственной тяжестью как только в проекте появятся еще разработчики кроме тебя. А если они еще и не успели набраться опыта и переболеть идеями что "изоляция убивает возможности"...

 

Как раз изоляция приложений упрощает жизнь разработчикам - каждый делает свое как хочет (а не оглядывается на уже написанные 100500 приложений, как бы их не развалить!), а все взаимодействия - по строгим документированным API. А ты всех в коммунальную квартиру поселить хочешь... 

 

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

[balabollng]

Думаю, мы принципиально расходимся в оценке технологий. HTML и JavaScript гениальные решения, которые опередили свое время. А гугл добавил современности обоим. До сих пор для Интернет не придумано ничего лучше HTML и JavaScript. И это просто факт. А уже не первый десяток лет!

 

Вопрос криворукости, это вопрос разработчика. Я не собираюсь "спасать" мир. Пусть он сам себя спасает Все, что я могу предложить - свой путь к "спасению" )) 

 

Но это лирика. Теперь по сути:

 

1. Зачем изоляция приложений? Чтобы что? Возьмем серверные движки такие, как к примеру, Jomla. Там ты делаешь модули подчиненные правилам, заданные архитектурой. Никакой изоляции модулей нет. Можно хоть всю Jomla ушами кверху поставить. Но зачем? Моя политика ровно такая. Я запускаю приложение в общем контексте, даю приложению все необходимые инструменты для комфортной работы в среде. Если разработчик ушел "влево", это проблема разработчки. Может так оно и должно быть.

2. Уже сейчас все вопросы с управлением модулями скриптов решены. Никаких проблем с разваливанием не будет. Просто потому, что вызовы в системе реализованы через косвенные связи. Скажем для вызова активности, нужно выполнить следующие действия:

 

var mainActivities = this.queryActivities({

            "action-filter" : [

                     "MarineWRT.Actions.Launch"

           ]

});

 

Тут мы выбираем все активности, соответствующие заданному фильтру. В частности те, которые являются стартовыми (могут запускаться). Узнаем их имена и расположение. 

 

var int = new $intent(this);

 

int.setFilter({

"application" : "appname",

"name" : "main"

});

 

int.setAction("MarineWRT.Actions.Launch");

 

this.launchActivity(int);

 

А тут мы формируем команду для передачи всем активностям, подходящим по фильтру. В частности - запуск. 

 

Т.е. никакой прямой связи с JavaScript модулями нет. Разработчику о модулях ничего знать не нужно. Даже задумываться о них. Если под фильтр попадет 10 активностей, все они получат то, что передано в объекте @intent и выполнят то, что будут считать необходимыми.

 

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

[balabollng]

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

 

Ничего подобного, что я делаю нигде нет. 

 

Прошу привести пример, как можно разработать только на JavaScript приложение, которое сможет управлять модулем Arduino. Т.е. не трогая более ничего, ни серверные скрипты, ни скетчи.

[balabollng]

В общем, я решил из баги сделать фичу.

 

И так, стили в рамках MarineWRT будут объявляться через специальный тег "MWRT-STYLE"

 

В самом теге, можно будет прописать путь к файлу стилей или как в теги style описать сам стиль. Вот так

 

<MWRT-STYLE>

 

   $$.myclass {

   }

 

</MWRT-STYLE>

 

 

В общем-то самое интересное тут $$, вместо него ядро будет подставлять родительский класс. 

 

Но, если очень хочется, то можно будет переопределить стиль глобально. Собственно зачем это позволяется? 

 

Берем тот же louncher. Сейчас он в жестких рамках самого себя и Bootstrap, как и любое приложение. В случае такой концепции, launcher сможет глобально переопределять стили, для приложений, которые не очень стремятся к индивидуальности. Т.е. те, котому пофиг, как оно будет выглядеть.

 

Тем, же кому не пофиг, всегда смогут переопределить любой глобальный стиль на свой лично для себя через $$.

 

Да, и еще, стили выгружаются при завершении приложения. Не важно, были ли они глобальными или локальными. 

[avfv]

Не знаю как в joomla, а вот гениальные html/js технологии получились такими, что страница имеет огромный глобальный контекст. И ничего с этим сделать нельзя. Ну, можно конечно наложить на приложения 100500 ограничений - но это не даст никаких гарантий что глобальные переменные / стили / идентификаторы элементов / библиотеки не пересекутся. 

 

Думаю, что невозможность использования в приложениях любимых версий любимых фреймворков приведет к тому, что желающих их писать будет маловато. 

 

Можно, конечно, считать что раз больше никто "напрямую из js ардуиной не управляет", то такой системе все косяки и ограничения простят. 

[balabollng]

Андрей, это не прощение. Это философия.

 

Вы стоите на строгом изолировании. Но любое изолирование вещь условная. Любую изоляцию можно обойти, ели знать как. 

 

Так зачем же она? Ответ прост - изоляция нужна для устойчивой работы системы в целом, при локальных сбоях. Т.е., если у вас упало одно приложение, оно не должно "завалить" всю систему. 

 

Теперь, давайте спросим себя, чего мы так трясемся над этой системой? 

 

Потому, что она для нас является фундаментом наших процессов. Т.е. упавшая система прекращает деятельность всех процессов.

 

 

Но в корне не верно транслировать все это в WEB страницу. WEB страница на клиенте живет неопределенное время. И живет она на самом деле offline. Клиент забрав контент может неделю сидеть локально и только в конце нажать кнопку "next"... при этом ситуация на сервере давно изменилась....

 

Т.е. WEB страница не несет фундаментального значения для работы системы. Система сама по себе существует, а отданный контент на клиенте сам. Подчеркиваю, фундаментальнийшую причину изоляции процессов мы смело откидываем. И в MarineWRT ситуация ровно такая же. Никакое падение приложения не приведет к падению системы в целом. 

 

Следовательно, никакой критичности в изоляции просто нет. 

 

Видимо Вы не погружались в Android. Минимальное погружение покажет, что современные приложения давно инкапсулируют собственный функционал. Изоляция становится условной. И это совсем не плохо. Удобно использовать функции одного приложения из другого.

[balabollng]

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

 

Вы меня не слышите Я никакие ограничения накладывать не собираюсь. Я предлагаю "условия игры". Хочешь - играй. Не хочешь - не играй. 

 

Вопрос простой - на какой шут лезть в MarineWRT со своими правилами, чтобы играть в свою игру? Бери, да делай все по старинке. Поднимай отдельный WEB сервер, кодь на PHP, получай геморрой с подключением Ardouno по неясным интерфейсам и т. п.

 

Есть старая русская поговорка - в чужой монастырь со своим уставом не лезут. И тут ровно такое правило. Да, в монастыре можно устроить оргии и разврат. Но там такого нет. Почему? Потому, что люди туда приходят за другим. 

 

Хотя идея изоляции вполне релевантна для монастыря.... только такой монастырь уже называется - тюрьма

[avfv]

Да, знакомая такая философия. Наверное, все начинающие разработчики проходят этап, когда любое средство изоляции и структурирования кода воспринимается в штыки и как вызов их мастерству хакера. Зачем все это, если можно сломать при желании? И только с опытом (написания больших программ) приходит понимание, что все это не просто так, а инструменты позволяющие большие программы создавать, да чтобы стоимость их поддержки не росла по экспоненте.

 

В данном случае изолирование приложений в своих iframe-ах это не способ добиться стабильности, а возможность каждому разработчику делать то, что ему нравится, не конфликтуя с остальными. Вот кто-то написал на angular 1.4, другой на 1.2, а третий вообще свой форк использует. 

 

Позиция "вот вам моя версия jquery, а если кому не нравится - в другой монастырь." в принципе логична и понятна, но популярности платформе не принесет.

[balabollng]

Андрей, простите, но Вы так и не поняли сути.

 

А я уже свои ОС и интерпретаторы 10 лет назад отписал. Думаю, Вы даже не знаете, что такое защищенный режим x86, и как реализуется подкачка страниц памяти на уровне прерываний. Это я не меряюсь длиной... эм.. своего ума. Я просто хочу, чтобы Вы поняли, что то, о чем Вы теоретизируете, я не просто знаю, я это через себя пропустил.

 

Так, вот, это все ерунда. Настоящая сила в косплотформенности и языках высокого уровня. Таких как Java, JavaScript и т. п. Все прочее уже прошлый век. 

 

Изоляция путь в некуда. 

[avfv]

Ну думаю что суть я понял верно: у Вас приложений по сути нет. Есть куски js, html, css которые ядро подгружает в себя и лепит из них одно общее приложение. А потом пробует со всем этим взлететь. Если не получилось - ну это пользователь виноват, надо было выбирать только совместимые комбинации приложений... Основные проблемы тут будут даже не с кодом приложений, тут как-то можно еще извернуться - скажем тотальным префиксованием идентификаторов, а с толстыми js библиотеками, без которых современная разработка web-интерфейса немыслима. Связывание с данными через findElementById сегодня никто уже не делает.

 

И вот интересно - регистры и ассемблер тогда еще 486 мне были любопытны лет 15 назад. Сейчас я уже не вспомню, сколько и каких бит в каком дескрипторе, и зачем нужен регистр CR0... но вот программы почему-то получается писать гораздо лучше

 

К слову, основная причина разработки Java это вовсе не кроссплатформенность, а как раз желание сделать язык в котором исполняемые модули будут по возможности изолированы от ОС и друг от друга. Почитайте про ОС Singularity, там написано зачем вообще нужен управляемый код. Кроссплатформенность у него это побочный по сути бонус, не всегда реализованный.

[balabollng]

Предлагаю дискуссию прекратить. Время все по местам расставит.

Я совершенно уверен в верности подхода. Остальное ерунда. Кому нужно будет, будут использовать, кому нет - не будут.

[balabollng]

Есть интересная новость.

 

Я переписываюсь с ребятами, которые создали неплохую студию по программированию на JavaScript. Ее значительное преимущество в том, что она работает как приложение Chrome. К исходникам обращается по FTP или SFTP на ваш сервер. 

 

Им показалось интересной идея создания плагина заточенного под разработку для MarineWRT. 

 

По сути, от них ничего принципиального не нужно будет, за исключением того, что в команде "New" появится еще один шаблон.

 

А вот я сделаю интересную штуку, чтобы все это работало. И так:

 

1. На сайте MarineWRT будет некий фидер, нечто вроде прокси-севера для ftp. Его задача будет перенаправлять ftp команды на хост MarineWRT разработчика.

2. Разработчик регистрируется на MarineWRT автоматом получая ftp пользователя. Система сообщает ему параметры синхронизации его хоста с сайтом.

3. Разработчик вводит все параметры синхронизации и получает подтверждение, что все ok.

4. Разработчик заходит в студию, указывает параметры соединения по ftp, адресом которого будет сайт ftp.marinewrt.org, а пользователем его учетная запись. 

5. Студия подключается на фидер, который связан с хостом MarineWRT.

6. Разработчик разрабатывает

 

В итоге, получится единая, прозрачная конва для разработки.

 

Если идея попрет, ребята готовы делать больше

[balabollng]

Лучше один раз увидеть, чем 100 раз прочесть 

 

https://youtu.be/GKwp6L9OqSc