[Freeschool] учебный софт под Линукс

[Anton Farygin]

Maksim Otstavnov wrote:
> Hello Anton,
> 
> Monday, December 29, 2003, 6:18:26 PM, you wrote:
> 
> AF> Aleksey Novodvorsky wrote:
> 
>>>Anton Farygin пишет:
>>>
>>>
>>>>Я не считаю браузер правильным движком.. тем более вкупе с apache + SQL.
>>>>
>>>>Тем более - кроссплатформенным. ;-( 
>>>
>>>
>>>Вот последняя фраза совсем непонятна?
> 
> 
> AF> Гонять апач + базу под Windows приравневается к сексу стоя в гамаке ;-)
> 
> Вот пусть виндузяткики и потрахаются. Чего ты за них переживаешь?
> 
> 
>>>Возможно, спорить здесь бессмысленно. Есть ведь браузеры и на Qt, почему
>>>бы еще один не написать?
> 
> 
> AF> Не нужен браузер. Нужен специализированный движок, отрабатывающий 
> AF> специализированный управляющий контент.
> 
> Что за чудо такое --- "управляющий контент"?
> 
> 
>>>В общем, затея писать новый движок, -- хороша, но малореальна, на мой
>>>взгляд. А опесорсить имеющиеся -- хм, я не видел достойных кандидатов, 
>>>тем более многоплатформенных. Завязыватсья же на поделки VB/Delphi/Kylix 
>>>-- на фиг-на фиг. Не расхлебаем.
> 
> 
> AF> Именно поэтому лучше не завязываться а писать свой. Правильный и OpenSource.
> AF> Завязываться на Mozilla - это так же проблематично, как и завязываться 
> AF> на VB/Delphi/Kylix.
> 
> Катастрофически не согласен, поскольку VBDK --- набор устаревших до
> рождения интерфейсов, а "Мозилла" --- набор адекватных и хорошо
> стандартизованных интерфейсов. Если тебе он потом не понравится, ты
> просто допишешь XUL для какого-нибудь "Конкерера" на своем любимом
> "QT", и все.

По моему я уже достаточно правильно сказал, что проблема не в отсутствии 
XUL для конкерера на моем любимимом QT, а проблема в самом XUL. В ДНК.


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

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

Его просто физически легче поддерживать.

> 
> AF> Слишком уж она нестабильна (местами)... да и что бы зафиксить багу в 
> AF> Mozilla, закопанную, например, глубоко в внутренний Cache - вообще 
> AF> нереально.
> 
> Это как это нереально?

Есть ошибки, заложенные при проектировании.. в Mozilla таких - много.

> 
> AF> Не зря разработчики Mozilla не могут исправить уже несколько лет ряд 
> AF> критичных ошибок, одна из которых - пожирание памяти в объемах несколько 
> AF> гигабайт на тривиальном документе с нетривиальной картинкой (тот же NS 4 
> AF> умел это нормально отображать)... или например фокусировка в сложном 
> AF> документе с несколькими слоями.
> 
> Вот и исправим.
> 

Я не наблюдаю на территории рунета специалистов, способных исправить 
архитектурную ошибку в Mozilla за разумное время.

С учетом того, что там примерно 1000 мегабайт тяжело читаемого C++ кода.

Rgds,
Rider