OberonCore

Кстати, в продолжение темы «Графический интерфейс BlackBox для Linux», нашел статью Разработка Web-приложений для локального применения
Такой подход к вопросу кажется более современным. Кроме этого, он поддерживает дух минимализма, присущий ВВ. В то же время такая технология может использоваться в мультимедиа
Многофункциональный мультимедийный компьютер: Часть 5. Удаленный и локальный интерфейс

Из проблемJava-апплеты показали, что графика, отображаемая браузером, может быть качественной. В случае с ВВ, он может быть скомпонован в dll-ку или so-файл.

Что вы хотите достичь этим? Тут дело не в интерфейсе. По определению - веб приложения - это приложения работающие под управлением браузера . ББ в этом смысле очень на него похож - по замыслу создателей это маштабируемая ,модульная , легко конфигурируемая (ну все в этом мире относительно ) IDE позволяющая запускать приложения. Точнее создаваемые приложения являются ее составной частью ( другие программы с аналогичным подходом -MAPLE, VFOXPRO ...). При попытке предлагаемой Вами интеграции - эта составляющая будет либо убита (по сути дела мы будем иметь традиционную IDE) (но даже в этом случая функциональность создаваемых с помощью такой среды приложений будет ограничена - браузерки имеют довольно серьезные ограничения на функционал - из -за повышенных требований к безопасности), либо мутирует во что-то непонятное (при условии завершения процесса мутации конечно) -вы согласны инициировать мутацию?
По поводу веб - сред - рекомендую просто посмотреть на PABC - WEB - пока она выглядит примитивно - но даже если они сделают супер пупер ide (как скажем в опере dragonfly) - возможности программ создаваемых с помощью этой среды будут заведомо ограничены (другое дело что для нужд образования они достаточны (вроде бы))

Да обратите внимание -
1. Ограничения текущих браузерок настолько существенны
2. Потенциальные преимущества таких приложений (с точки зрения рынка) велики (тут и издержки на сопр. и т. д.),
что Гугл просто напросто создает свою WEB OS - система где все пляшет от браузера, для получения прибыли

Посмотрите в сторону ББ (я говорю про бутылку ) - это система где все пляшет от среды выполнения (IDE), в сторону - а в какую сторону? одному богу известно...
Если уж фантазировать, тогда просто может представим -WEB OS - на основе оберона - тем более что ОС существует уже давно - просто сейчас она бесцельная , созданная гиком чисто с академической целью и сейчас свободно мутирует... Может просто научиться управлять мутацией? Да на форуме есть люди которые ковыряются в ней - может попросим их высказаться по сабжу?

Пока это просто тема для обсуждения. Понять тенденции и не заниматься устаревшими технологиями.
Я не спорю с Вашими утверждениями, но делаю из них противоположные выводы. Функционал браузеров зависит от активных компонентов, плагинов и т.д. Значит, его можно использовать как интерфейс к программам. Интерфейс этот нужен для кроссплатформенности. Получится «традиционная IDE», но кроссплатформенная. Это никак не влияет на реализованный ВВ под Windows, который компилируется и в dll-ку, и в so-файл при сохранении всего функционала программ. Только эти программы запускаются при помощи браузера. Значит, дело только в интерфейсе. В общих чертах, как-то так…

Не получится без сужения возможностей создаваемых с помощью среды приложений ( например, псу под хвост уйдут системные приложения) и ЭТОТ вопрос в купе с утерей основной составляющей ББ -увы является фундаментальным, не говоря уж о остальных нюансах - а тут и так то не понятна "экологическая" ниша ББ.

Хотя, извините , если вы имеете ввиду плагины на основе инструментария движков- то это не веб приложение, у вас в этом случае получится нечто OIDE - А. Ильина- со всеми вытекающими последствиями (плагины это не есть полноценная IDE, + привязка к api конкретного браузера), - но зачем браузер ? есть java, есть еклипс, есть нетбинс, есть питон....

Вы считаете, что вначале надо определить для ВВ нишу?

Полагаю, что нужно просто развивать сетевые возможности ВВ. Это может происходить несколькими способами. Один из них – привязать GUI к вебу. Что потребует изменить принципы проектирования. Если в результате ВВ станет чем-то похож на уже существующие IDE, то это имеет второстепенное значение, как мне кажется.

ВВ от ОМС – качественный продукт. Каждый разработчик ПО использует его по мере своих возможностей и задач. Это естественная «хаотичность». Далее, есть проблема кроссплатформенности. Она не ограничивается одним ВВ. Есть вариант решения такой проблемы – использовать GUI на основе Web-технологий. Резюмируя созданную тему, сформулирую вопрос. Поддержит ли Оберон-сообщество данную технологию? Имеет ли она перспективу?

Я думаю, что это интересное направление, если есть желание - почему бы не попробовать.

К отличиям в подходах при разработке из старой(2004г.) статьи «WEB vs GUI: точка зрения разработчика» я добавил бы возможности и проблемы Web 3.0(Semantic Web), который актуально интегрировать. Его необходимо, как мне кажется, учитывать уже при проектировании.

Стоп-стоп.

Тут Вы должны определиться, что Вас интересует. ББ как платформа для разработки веб-приложений - это одно. Это, кстати, ну никак не связано с наличием Веб-интерфейса к блэкбоксовуму ГУЮ. Тут ББ применяется просто как среда программирования для кросс-разработки приложения, неграфически исполняемого на сервере.

Либо браузерный ГУЙ к ББ. Тут надо начинать просто с режима, когда неграфический ББ работает по localhost для одного пользователя, который через браузер видит обычный документный ГУЙ. И ни в коем случае не заморачиваться Веб-приложениями вообще. И только после успешного решения этой задачи можно подумать а том, а что будет если скрестить ББ-шный ГУЙ и веб-приложения.

При втором направлении Web 3.0 не должен Вас беспокоить. Берёте минимум основных стандартов W3 - XHTML 1.1, CSS и ECMA Script (стандарт на Java Script + единственная, по словам автора JS и моим наблюдениям тоже, приличная книга про него - Д. Флэнагана), XMLHttpRequest в оном Ява Скрипте (только лучше, видимо, без XML ) - и вперёд.

---
Если же говорить о Semantic Web - то это тупик. Реальные проблемы пытаются решить заведомо провальным способом - составлением априорных классификаций, таксономий, в которые никакое содержание потом не втиснешь, да и никто не будет этим заниматься... В области искусственного интеллекта и комп. лингвистики сто раз проверено; старые блуждания из той области просто "пролились" в среду Web-инженеров, которые ими возгорелись, когда специалисты по лингвистике уже перегорели.
---

Давайте на более понятном языке , вот вам http://pascalabc.net/WDE/ - малобюджетный вариант web - среды в классическом смысле. Поиграйтесь с ним, посмотрите форум , попытайтесь зафиксировать принцип работы, возможную область применения. Далее просто связанно сформулируйте - что вы хотите (в сравнении с тем что есть) видеть в своем проекте. Хотя бы по двум критериям
1. Область использования создаваемых с помощью нее приложений
2. Внешний вид

А какой может быть внешний вид... Надо думать, как документы и окна организовать в браузере, а в остальном - текстовый документ с вьюхами, спроецированный в активный XHTML.

В общих чертах я определяю задачу для себя так.

Браузерный GUI для ВВ – это браузер с плагином или надстройкой в виде dll-ки из ВВ, который запрашивает с сервера, в простейшем случае по localhost, весь недостающий функционал. Сервер может быть любым, но он должен предоставить доступ к ресурсам компьютера(например, технология FastCGI). Если сервер не имеет запрашиваемых ресурсов, тогда он должен передать ссылку на другой сервер, про который известно, что такие ресурсы присутствуют. Этот обмен информацией должен производиться по уже разработанному протоколу. Если не Web 3.0, тогда что? Подчеркну, что запрашиваемые ресурсы могут быть абсолютно разные: от конкретной процедуры в бинарной библиотеке.

Про такой вариант сложилось мнение, что смысла в нём нет. Либо настольное приложение, либо - чистый, любой браузер без плагинов. Текущие веб-стандарты с использованием JavaScript дают возможность это сделать - для localhost точно.



Стоит применить опубликованные блэкбоксовые HTTP-серверы O3 или Dbu (см. коллекцию Цинна). Они работают на основе Services.Action - и в графическом ББ малопроизводительны, но при сборке неграфического приложения дадут производительность, достаточную даже для динамических сайтов, не то что для одного пользователя по localhost. Сделайте изолирующую прослойку, чтобы не зависеть от конкретного HTTP-сервера и перейти на возможные новые - и работайте.


Здесь не совсем понятно, зачем Вам Web 3.0. Это - не протокол, а некое семейство подходов для организации веб-ресурсов и веб-систем.
Просто решайте конкретную задачу - и прикладной протокол вырастет сам, тот, который Вам нужен.

Уже сейчас видно, что Вы смешиваете несколько желаний: реализовать GUI в браузере и поэкспериментировать с некими способами распределения приложений ("грузить" что-то откуда-то и т.п.)
Смешивать задачи, видимо, не стоит, они сильно разные.

Причем тут веб gui -вы описываете обычное клиент серверное (в общем случае ) приложение. Предлагаете писать его через зад. У вас даже нет кроссплатформенности =хуже того предполагается привязка к api конкретного браузера, впрочем об этом я писал

Есть интересная тема трансляции документного ГУЯ средствами браузера. Она сама по себе не связана с Web. Её можно обкатать отдельно, в режиме однопользовательского локального клиент-сервера. И, как следствие, получить кроссплатформенный ГУИ для ББ. Кросс(двух)платформенность неграфической серверной части очевидна. Как второе следствие, уже потом, можно искать применения этого механизма (трансляции документного ГУЯ) в сфере веб-приложений.

Вот так можно было бы ставить задачу.

Речь идет о отображении такого типа
ODC (как визуальная структура)+код модуля-> xhtml+js?

Да, видимо, что-то вроде этого.

Сразу надо сказать - это подход (лобовое отображение текущих ODC и вьюшек BlackBox Framework) не нужно пытаться тащить в полноценные Веб-приложения, не получится. Это будет работать для локальных приложений, потом можно легко масштабировать для бизнес-приложений в локальной сети (а это уже, в принципе, некоторая ниша. Кстати, и для образовательных применений).

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

Наверно, нужно вначале определить некие аксиомы.

Используем или нет другие ЯП?

Сошлюсь на документациюПосле такого утверждения переключаться на JavaScript – не лучший вариант.

Что считать кроссплатформенностью в данном случае? И т.д.