Андрей!
Ты мощный!
Я уже наверно более 7 лет смотрю на твое творчество. Ты делаешь классные красивые грандиозные вещи. Желаю тебе успехов!
Также молодцы те кто тебе помогает в программировании. Всем привет!
Рассматриваю возможность создания open source версии движка.
Основной целью является на самом деле не open source как таковой/ая, а скажем так модульность.
Есть разные задачи требуют всё вплоть до UI rendering и есть задачи в которых нужна просто какая-то часть.
Скажем кому-то нужно просто парсить HTML чтобы получить DOM. Плюс опционально иметь возможность делать запросы/выборки используя механизм CSS selectors.
Кому-то нужна возможность получить по RTL строке последовательность glyphs. Кому-то нужен DOM rendering но с другим входным языком — не HTML а скажем XHTML2 и т.д.
А кому-то нужен полномасштабный rendering с динамикой но Python или Ruby на борту. Кому-то просто нужна кроссплатформенная билиотека для рисования/векторной графики.
Кому-то нужен только http client который позволяет с'эмулировать <form action=... method=post> и пр.
Проблема на настоящий момент состоит в том что все существующие движки (open source или не очень) представлют собой некие монолитные конструкции из которых ни выдрать чего-то ни добавить чего-то свое невозможно. Собственно вот эту проблему и хочется как-то разрешить.
При наличии инициативной группы товарищей реально в течении 6 месяцев сделать эффективный (компактный и шустрый) движок который пройдет скажем ACID2 тест. Я исхожу из того что большая (бОльшая либо большАя) часть этого проекта в виде идей и кода может быть взята из H-SMILE core практически как есть.
Про коммерческую сторону сего мероприятия говорить наверное рано но могу сказать что в свете всяко разных мобильных платформ в последнее время можно ожидать интереса от сильных мира сего. Во всяком случае я чувствую интерес от 2 компаний из скажем так большой десятки.
Кому-то из присутвующих интересно сие мероприятие?
On 10/10/10 07:58, cgibin wrote:
> А порт на другие платформы в это начинание входит? И есть ли > какие-нибудь подвижки в этом направлении?
У нас есть подвижки, сейчас оно компилится под gcc/linux с QT-backend, однако слишком мало времени уделяем.. медленно идёт.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, c-smile, Вы писали:
CS>Основной целью является на самом деле не open source как таковой/ая, а скажем так модульность.
Модульность это что? Множество LIB, множество DLL, одна DLL разные части которой общаются через публичный интерфейс?
CS>Скажем кому-то нужно просто парсить HTML чтобы получить DOM. Плюс опционально иметь возможность делать запросы/выборки используя механизм CSS selectors.
DOM штука религиозная. Есть очень много уровней реализации DOM и очень много способов реализовать парсер. Упомяну лишь DOM Events и invalid HTML. Я не думаю что получится универсальный повторноиспользуемый парсер, скорее кусок H-Smile с публичным интерфейсом. Над тем DOM который в HTMLayout нельзя надстроить XPath, к слову. А можно ли будет таким парсером парсить исходный код asp.net страниц?
CS>Кому-то нужна возможность получить по RTL строке последовательность glyphs. Кому-то нужен DOM rendering но с другим входным языком — не HTML а скажем XHTML2 и т.д. CS>А кому-то нужен полномасштабный rendering с динамикой но Python или Ruby на борту. Кому-то просто нужна кроссплатформенная билиотека для рисования/векторной графики. CS>Кому-то нужен только http client который позволяет с'эмулировать <form action=... method=post> и пр.
Очень много задач, как бы не распылить силы.
CS>При наличии инициативной группы товарищей реально в течении 6 месяцев сделать эффективный (компактный и шустрый) движок который пройдет скажем ACID2 тест. Я исхожу из того что большая (бОльшая либо большАя) часть этого проекта в виде идей и кода может быть взята из H-SMILE core практически как есть.
ИМХО не стоит исходить из этой идеи. Текущий DOM точно слишком специфический и заточен под конкретную задачу. Если ты поменяшь DOM, то что останется не тронутым?
CS>Кому-то из присутвующих интересно сие мероприятие?
Я могу стоять рядом и махать флажками. На Си++ по доброй воле ничего большого писать не буду.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, c-smile, Вы писали:
CS>>Основной целью является на самом деле не open source как таковой/ая, а скажем так модульность.
A>Модульность это что? Множество LIB, множество DLL, одна DLL разные части которой общаются через публичный интерфейс?
В C++ модульность как правило заключается в разбиении проекта на самодостаточные libs.
DLL это уже компонентность — т.е. абстракции следующего уровня.
CS>>Скажем кому-то нужно просто парсить HTML чтобы получить DOM. Плюс опционально иметь возможность делать запросы/выборки используя механизм CSS selectors.
A>DOM штука религиозная. Есть очень много уровней реализации DOM и очень много способов реализовать парсер. Упомяну лишь DOM Events и invalid HTML. Я не думаю что получится универсальный повторноиспользуемый парсер, скорее кусок H-Smile с публичным интерфейсом. Над тем DOM который в HTMLayout нельзя надстроить XPath, к слову. А можно ли будет таким парсером парсить исходный код asp.net страниц?
Ничего особо религиозного там нет.
Вот собственно:
namespace dom
{
class node
{
element* parent; ...
}
class text: public node
{
...
}
class element
{
collection<node*> nodes;
}
}
и никакой саентологии.
CS>>Кому-то нужна возможность получить по RTL строке последовательность glyphs. Кому-то нужен DOM rendering но с другим входным языком — не HTML а скажем XHTML2 и т.д. CS>>А кому-то нужен полномасштабный rendering с динамикой но Python или Ruby на борту. Кому-то просто нужна кроссплатформенная билиотека для рисования/векторной графики. CS>>Кому-то нужен только http client который позволяет с'эмулировать <form action=... method=post> и пр.
A>Очень много задач, как бы не распылить силы.
Я не понял про "много задач". Все эти модули там есть и так. Т.е. можно их и сейчас выставить наружу но API получается зело объемный.
Да и сомневаюсь я что для просто рисования в каком-нибудь проекте имеет смысл таскать за собой полный engine.
CS>>При наличии инициативной группы товарищей реально в течении 6 месяцев сделать эффективный (компактный и шустрый) движок который пройдет скажем ACID2 тест. Я исхожу из того что большая (бОльшая либо большАя) часть этого проекта в виде идей и кода может быть взята из H-SMILE core практически как есть.
A>ИМХО не стоит исходить из этой идеи. Текущий DOM точно слишком специфический и заточен под конкретную задачу. Если ты поменяшь DOM, то что останется не тронутым?
Ничего особо специфического в DOM нет. Или я тебя не понял.
CS>>Кому-то из присутвующих интересно сие мероприятие?
A>Я могу стоять рядом и махать флажками. На Си++ по доброй воле ничего большого писать не буду.
Кроме как С++ другой альтернативы нет. Разве что D.
Здравствуйте, c-smile, Вы писали:
CS>Кому-то из присутвующих интересно сие мероприятие?
Интересно. Реальное участие принять вряд ли смогу. Недавно поменял работу и профиль, поэтому пашу как вол, времени на хобби в принципе не остается. Если все пойдет как надо (тьфу*3) после нового года оживлю http://htmlayoutlab.com/, ибо идей интересных тьма и есть силы и желание их реализовать.
Здравствуйте, c-smile, Вы писали:
CS>В C++ модульность как правило заключается в разбиении проекта на самодостаточные libs. CS>DLL это уже компонентность — т.е. абстракции следующего уровня.
То есть за пределами Си++ от твоей модульности толку мало.
CS>Ничего особо религиозного там нет. CS>Вот собственно: CS>
CS>namespace dom
CS>{
CS> class node
CS> {
CS> element* parent; ...
CS> }
CS> class text: public node
CS> {
CS> ...
CS> }
CS> class element
CS> {
CS> collection<node*> nodes;
CS> }
CS>}
CS>
CS>и никакой саентологии.
Поверх такого DOM нельзя построить XPath. Об чём и речь, обственно.
CS>Я не понял про "много задач". Все эти модули там есть и так. Т.е. можно их и сейчас выставить наружу но API получается зело объемный.
Все модули есть в нужном тебе объёме, но не в объёме обобщённого решения задачи.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, c-smile, Вы писали:
CS>>В C++ модульность как правило заключается в разбиении проекта на самодостаточные libs. CS>>DLL это уже компонентность — т.е. абстракции следующего уровня.
A>То есть за пределами Си++ от твоей модульности толку мало.
Ты путаешь модульность и компонентность.
Можно сделать скажем компонент для .NET (dll) который будет включать модули DOM, CSS, parser.
Как в принципе можно собрать sciter но без скрипта. Получится компонент htmlayout.
CS>>Ничего особо религиозного там нет. CS>>Вот собственно: CS>>
CS>>namespace dom
CS>>{
CS>> class node
CS>> {
CS>> element* parent; ...
CS>> }
CS>> class text: public node
CS>> {
CS>> ...
CS>> }
CS>> class element
CS>> {
CS>> collection<node*> nodes;
CS>> }
CS>>}
CS>>
CS>>и никакой саентологии.
A>Поверх такого DOM нельзя построить XPath. Об чём и речь, обственно.
XPath — легко. Ибо это стандартная структура XML и HTML домов.
CS>>Я не понял про "много задач". Все эти модули там есть и так. Т.е. можно их и сейчас выставить наружу но API получается зело объемный.
A>Все модули есть в нужном тебе объёме, но не в объёме обобщённого решения задачи.
Этой сентенции я не понимаю. Что-то про щастя всем и бесплатно?
Здравствуйте, c-smile, Вы писали:
A>>Поверх такого DOM нельзя построить XPath. Об чём и речь, обственно. CS>XPath — легко. Ибо это стандартная структура XML и HTML домов.
А вот и нет. HTML attribute у тебя не node. XPath умеет выбирать атрибуты, с твоим DOM это не выйдет.
CS>>>Я не понял про "много задач". Все эти модули там есть и так. Т.е. можно их и сейчас выставить наружу но API получается зело объемный. A>>Все модули есть в нужном тебе объёме, но не в объёме обобщённого решения задачи. CS>Этой сентенции я не понимаю. Что-то про щастя всем и бесплатно?
Даю конкретный пример — XML namespaces вообще, парсинг ASP.Net маркапа в частности.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, c-smile, Вы писали:
A>>>Поверх такого DOM нельзя построить XPath. Об чём и речь, обственно. CS>>XPath — легко. Ибо это стандартная структура XML и HTML домов.
A>А вот и нет. HTML attribute у тебя не node. XPath умеет выбирать атрибуты, с твоим DOM это не выйдет.
Надо — будет node. Вопрос лишь надо ли это или нет.
По определению:
Attr objects inherit the Node interface, but since they are not actually child nodes of the element they describe, the DOM does not consider them part of the document tree. Thus, the Node attributes parentNode, previousSibling, and nextSibling have a null value for Attr objects.
т.е. технически я или кто-то другой может нариcовать HTMLayoutGetAttribute(name,Node**);
но на этом вся любофф с .NET и закончится. Получается дикое количество объектов которые нужно manage.
CS>>>>Я не понял про "много задач". Все эти модули там есть и так. Т.е. можно их и сейчас выставить наружу но API получается зело объемный. A>>>Все модули есть в нужном тебе объёме, но не в объёме обобщённого решения задачи. CS>>Этой сентенции я не понимаю. Что-то про щастя всем и бесплатно?
A>Даю конкретный пример — XML namespaces вообще, парсинг ASP.Net маркапа в частности.
Я не вижу особой проблемы с XML namespaces кроме кучи деталей которые нужны в 1% use cases.
Собственно для этого и есть модульность. Теоретически можно сделать модуль DOM параметризуемый макро типа #define DOM_level 1|2|3.
По ходу дела я тут руковожу созданием UI одной высоконагруженной системы в которой мы вообще отказались от
динамических страниц формируемых сервером. Сугубо статические html + JSON RPC на web services.
Здравствуйте, c-smile, Вы писали:
CS>Надо — будет node. Вопрос лишь надо ли это или нет.
Вопрос лишь в том, делаешь ли ты доступными публично кусочки H-Smile или решения задач.
CS>но на этом вся любофф с .NET и закончится. Получается дикое количество объектов которые нужно manage.
Если объекты мелкие, то это фигня. Глпавное чтобы в Large Object Heap не попали.
A>>Даю конкретный пример — XML namespaces вообще, парсинг ASP.Net маркапа в частности. CS>Я не вижу особой проблемы с XML namespaces кроме кучи деталей которые нужны в 1% use cases.
Опять таки вопрос: в чём смысл модульности, если модули нельзя использовать отдельно из-за функциональных органичений, которые отсутствуют в других решениях?
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, c-smile, Вы писали:
CS>>Надо — будет node. Вопрос лишь надо ли это или нет.
A>Вопрос лишь в том, делаешь ли ты доступными публично кусочки H-Smile или решения задач.
External API он кушать просит. Каждая внешняя функция это врапер одной или нескольких internal функций.
В таком врапере наличествует проверка параметров на допустимость, threading контроль и пр.
Т.е. external API бесплатно (в смысле счастья) не дается. Т.е. просто так взять и выставить всё наружу — мало не покажется.
CS>>но на этом вся любофф с .NET и закончится. Получается дикое количество объектов которые нужно manage.
A>Если объекты мелкие, то это фигня. Глпавное чтобы в Large Object Heap не попали.
Объекты со своим life cycle т.е. disposable и пр. Нагружать GC деталями структуры DOM это технически не верно.
Т.е. DOM он всегда будет native. Не только по причинам GC кстати.
A>>>Даю конкретный пример — XML namespaces вообще, парсинг ASP.Net маркапа в частности. CS>>Я не вижу особой проблемы с XML namespaces кроме кучи деталей которые нужны в 1% use cases.
A>Опять таки вопрос: в чём смысл модульности, если модули нельзя использовать отдельно из-за функциональных органичений, которые отсутствуют в других решениях?
Если у тебя есть задача скажем отображать DOM и при этом как-то не тривиально с ним работать то
ты будешь использовать DOM модуль в обоих случаях. Иначе у тебя получается rendering с одним DOM а обработка с другим. Т.е. вся система в два раза больше и соотв. в два раза подвержена ошибкам.
Здравствуйте, c-smile, Вы писали:
A>>Опять таки вопрос: в чём смысл модульности, если модули нельзя использовать отдельно из-за функциональных органичений, которые отсутствуют в других решениях? CS>Если у тебя есть задача скажем отображать DOM и при этом как-то не тривиально с ним работать то CS>ты будешь использовать DOM модуль в обоих случаях. Иначе у тебя получается rendering с одним DOM а обработка с другим. Т.е. вся система в два раза больше и соотв. в два раза подвержена ошибкам.
Весьма спорное утверждение. Если я ради XPath буду использовать не твой парсер, а Xerces или MS XML вряд ли надёжность решения упадёт. Скорее наоборот, уж не обижайся.
Здравствуйте, adontz, Вы писали:
A>>>Опять таки вопрос: в чём смысл модульности, если модули нельзя использовать отдельно из-за функциональных органичений, которые отсутствуют в других решениях? CS>>Если у тебя есть задача скажем отображать DOM и при этом как-то не тривиально с ним работать то CS>>ты будешь использовать DOM модуль в обоих случаях. Иначе у тебя получается rendering с одним DOM а обработка с другим. Т.е. вся система в два раза больше и соотв. в два раза подвержена ошибкам.
A>Весьма спорное утверждение. Если я ради XPath буду использовать не твой парсер, а Xerces или MS XML вряд ли надёжность решения упадёт. Скорее наоборот, уж не обижайся.
Надежность решения в реальном мире это не только надежность некой функции API или их семейства.
Если рассматривать систему в целом то используя MS XML, мой DOM (или люой другой) плюс custom code их сопряжения и все это скажем в условиях Compact Framework получаем заведомо менее надежную систему которая использует скажем только мой DOM.
On 06/10/10 21:17, c-smile wrote: > По ходу дела я тут руковожу созданием UI одной высоконагруженной системы > в которой мы вообще отказались от > динамических страниц формируемых сервером. Сугубо статические html + > JSON RPC на web services.
Это GWT называется.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
On 08/10/10 00:26, c-smile wrote:
> .>Это GWT называется. > Это очень далеко от GWT которая "allows you to write client-side > applications in Java and deploy them as JavaScript".
А что именно тогда? Любопытно.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
.>On 10/10/10 07:58, cgibin wrote:
>> А порт на другие платформы в это начинание входит? И есть ли >> какие-нибудь подвижки в этом направлении? .>У нас есть подвижки, сейчас оно компилится под gcc/linux с QT-backend, однако слишком мало времени уделяем.. медленно идёт. .>
Сцитер под вайном вообще без проблем пашет, конечно есть потери в производительности, но это то с чем можно мириться, тобишь нужен ли порт под линух — вопрос...
Здравствуйте, kuzbas22, Вы писали:
.>>У нас есть подвижки, сейчас оно компилится под gcc/linux с QT-backend, однако слишком мало времени уделяем.. медленно идёт. .>> K>Сцитер под вайном вообще без проблем пашет, конечно есть потери в производительности, но это то с чем можно мириться, тобишь нужен ли порт под линух — вопрос...
Wine — это не выход. Есть ещё Android и прочие товарищи.
Здравствуйте, kuzbas22, Вы писали:
C>>Wine — это не выход. Есть ещё Android и прочие товарищи. K>А QT-backend его поддерживает, я просто не в курсах ?
При большом желании можно. Впрочем, план другой тут — написать бэкэнд на гугловском skia.
После нашего рефакторинга это, в принципе, работа на человеко-месяц.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, kuzbas22, Вы писали:
C>>>Wine — это не выход. Есть ещё Android и прочие товарищи. K>>А QT-backend его поддерживает, я просто не в курсах ? C>При большом желании можно. Впрочем, план другой тут — написать бэкэнд на гугловском skia.
C>После нашего рефакторинга это, в принципе, работа на человеко-месяц.
Это было бы мега — здорово!!
А что мешает ?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, kuzbas22, Вы писали:
C>>>Wine — это не выход. Есть ещё Android и прочие товарищи. K>>А QT-backend его поддерживает, я просто не в курсах ? C>При большом желании можно. Впрочем, план другой тут — написать бэкэнд на гугловском skia.
В принципе я имел ввиду Skia вариант, но на тот момент Skia не поддерживала HW-acceleration.
Вообще графический layer это вопрос вопросов.
На настоящий момент рассматриваю две опции:
1) AGG2D + GDI::TextOut (с хаком для альфа канала) поверх DirectX.8 — этот вариант будет работать на всех desktop Windows.
2) отдельный backend на Direct2D/DirectWrite — это только W7 и Vista с SP.
Вариант №1 в принципе более портируем на платформы с OpenGL.
На настоящий момент в проект нужен человек(и) на этот самый graphics layer. HTML/CSS core я сделаю сам.
Потом (лучше бы сразу конечно) потребуются люди на platform layer.
Кстати: в конце этого месяца я буду в гостях у компании на букву Г в городе-герое Mountain View. Может быть что-то еще более интересное получится.
Здравствуйте, ., Вы писали:
.>On 08/10/10 00:26, c-smile wrote:
>> .>Это GWT называется. >> Это очень далеко от GWT которая "allows you to write client-side >> applications in Java and deploy them as JavaScript". .>А что именно тогда? Любопытно.
Здравствуйте, c-smile, Вы писали:
C>>При большом желании можно. Впрочем, план другой тут — написать бэкэнд на гугловском skia. CS>В принципе я имел ввиду Skia вариант, но на тот момент Skia не поддерживала HW-acceleration. CS>Вообще графический layer это вопрос вопросов.
Угу.
CS>На настоящий момент рассматриваю две опции: CS>1) AGG2D + GDI::TextOut (с хаком для альфа канала) поверх DirectX.8 — этот вариант будет работать на всех desktop Windows.
Я после экспериментов пришёл к тому, что не стоит заморачиваться. Получится только ускорение композитинга, за счёт значительного усложнения всей архитектуры.
Значительное ускорение можно получить из отгрузки на видеокарту сложного рендеринга (всяких градиентов, антиализнутых линий и т.п.)
CS>2) отдельный backend на Direct2D/DirectWrite — это только W7 и Vista с SP.
Стоит заняться именно этим. Можно и D3D использовать с правильными шейдерами.
CS>Вариант №1 в принципе более портируем на платформы с OpenGL. CS>На настоящий момент в проект нужен человек(и) на этот самый graphics layer. HTML/CSS core я сделаю сам. CS>Потом (лучше бы сразу конечно) потребуются люди на platform layer.
У нас опять затык с временем, но в ближайшем будущем разгрестись получится. Но если есть что-то более-менее реальное, то можно сильно сосредоточиться.
On 14/10/10 08:42, c-smile wrote:
> behaviors сделаны по образу и подобию Sciter. Не так эффективно как у меня но тем не менее работают.
А в чём это эффективнее gwt? Меньше нагрузка на браузер?
Какие вообще плюсы?
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
.>On 14/10/10 08:42, c-smile wrote:
>> behaviors сделаны по образу и подобию Sciter. Не так эффективно как у меня но тем не менее работают. .>А в чём это эффективнее gwt? Меньше нагрузка на браузер? .>Какие вообще плюсы?
Еще раз: на сервере лежат статические страницы. Никакой код по преобразованию Java->JS на сервере не требуется.
Более того вообще используются WebApp manifests — т.е. для отдельных CSS, image файлов даже HEAD http requests не посылаются.
Сервер отдает сугубо JSON данные и фактически служит каналом однократной доставки версии приложения на клиент.
On 15/10/10 02:08, c-smile wrote:
> меня но тем не менее работают. > .>А в чём это эффективнее gwt? Меньше нагрузка на браузер? > .>Какие вообще плюсы? > Еще раз: на сервере лежат статические страницы. Никакой код по > преобразованию Java->JS *на сервере* не требуется.
Вообще-то преобразование Java->JS в gwt делается один раз — во время компиляции, на девелоперской машине|build-сервере. А на web-сервере лежат статические html/js и приложение для обработки ajax-запросов.
> Более того вообще используются WebApp manifests — т.е. для отдельных > CSS, image файлов даже HEAD http requests не посылаются. > Сервер отдает сугубо JSON данные и фактически служит каналом однократной > доставки версии приложения на клиент.
css можно встроить внутрь html. А картинки как? Не все браузеры data:-урлы поддерживают.
Хотя gwt поддерживает image bundles — все картинки сайта он может скомпилить в один файл и отдавать одним запросом.
Правда смысла всё делать одним запросом наверное не много, для раздачи статики можно поставить тучу тупых серверов.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
.>css можно встроить внутрь html. А картинки как? Не все браузеры data:-урлы поддерживают.
"text/cache-manifest" и http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html
.>Хотя gwt поддерживает image bundles — все картинки сайта он может скомпилить в один файл и отдавать одним запросом. .>Правда смысла всё делать одним запросом наверное не много, для раздачи статики можно поставить тучу тупых серверов.
Может вареников под это дело сделает в конце концов 
