Board.KolibriOS.org

Хорошая идея

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!

Тогда надо из этой темы выделить отдельно сообщения о ява-машине

Думаю, не обязательно. Если будут файлы, связанные непосредственно с JVM - тогда для них можно будет создать свою тему. А эта целиком посвящена перспективам браузера.

Здравствуйте. Я тут посмотрел написанное: Очень интересно.
Думаю что будет полезно обсудить все возможные пути и недостатки решений более систматично.
Тут несколько возможных решений:
1) Написать броузер с нулья
2) Портировать броузер (какой именно можно решить после)
3) Портировать JVM и адаптировать броузер на Java для портированной JVM.


Недостатки 1) в том что весь опыт написанных броузеров будет "растерян" и будут возникать проблемы преодаленный в существующих броузерах. Так что оптимизация и все подобные задачи могут занять очень долгое время. И еще в этом случае нужно учитывать что процессинг JS может создать массу проблем. Так как неизвестно какой код он будет транслировать. Вообще это достаточно нереалистичный путь по моему.

Про недостатки 2) можно сказать следующее. Каждый броузер расчитан на определенное количество ресурсов и соответсвенно оптимизирован. И при оптимизации часто учитывается специфика данной системы или платформы. Так что при портировке придется придется адаптировать оптимизацию для исходной платформы. По сложности это задача может быть сравнима с 1). Еще возникут сложности с лицензией и с "глупым" кодом который может потребовать массу усилий для исследования и портирования.

3) Портирование JVM и соответсвенно броузера это две разный задачи. Проблема вся в том что JVM нужно тестировать а тесты сами по себе займут уйму времени. Портирование VM это пол задачи но выявление багов и обработка "глупо" написанного кода это уже трудная и долгая задача. А еще компиляция броузера на портированной VM и выявление проблем тоже задача нетривиальная.

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

Вопрос в том чтобы выбрать более реалистичный подход. Я не уверен знакомы ли вы с проблемами возникающими в броузерах. Их не мало. Например одна из проблем связана с тем что вы не можете управлять код на странице и соответственно вы не можете знать наперед что получит броузер на вход. И приходится учитывать все возможные входы соответсвенно . Чтобы сделать поведение броузера более управляемым проведены исследования страниц и выявлены разные проблематичные проявления кода на странице. Думаю не реалистичным сбор статистики за короткый промежуток времени учитывая весь огромный спектр страниц в сети.
Кстати уверенность в своих силах полезна когда в процессе непреодалимых проблем нет:)

Прочитал раз, прочитал два, прочитал три... мозг выдал критическую перегрузку и обещал взорваться.
Пожалуйста изъясняйтесь на нормальной русском языке!

Mario, можно я?

Например, одна из проблем связана с тем, что вы не можете управлять кодом разметки, расположенным на странице, и, соответственно, вы не можете знать наперед, что получит броузер на вход. И посему приходится учитывать все возможные входы, соответственно. Чтобы сделать поведение броузера более управляемым необходимо проводить исследования страниц с целью выявления проблематичных участков HTML-кода на странице.

авторские права невыделенного текста принадлежат автору, выделенного - тоже автору, но другому (мне). Автора черного текста прошу поправить меня, ежели я где ошибся (можно зелёным, например)

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!

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

Извините за непонятный пост и спасибо to Gluk:) Так гораздо лучше

veg_nw, у любого браузера есть режим строгой разметки, причем в той же Опере для xhtml он (по крайней мере, в старых версиях) включен по умолчанию. То бишь чуть что - браузер паникует и ничего не показывает. Такой режим дисциплинирует веб-разработчиков, будучи активным на популярных браузерах. Давайте дисциплинировать веб-разработчиков =)

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!

Ну вообще то выбора то особого и нет:)
Все же написание с нуля потребует очень долгих тестов или очень строгих ограничений.
Я вообще то думаю что портинг наиболее реалистичное решение.

наиболее оптимальное предложение уже звучало - использовать клиент-серверные технологии. А то браузер в 100 раз больше чем сама система - извините меня...

Первый способ гораздо в духе данного проекта...