Рассматриваю возможность создания 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 компаний из скажем так большой десятки.
Кому-то из присутвующих интересно сие мероприятие?
Здравствуйте, 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
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Андрей!
Ты мощный!
Я уже наверно более 7 лет смотрю на твое творчество. Ты делаешь классные красивые грандиозные вещи. Желаю тебе успехов!
Также молодцы те кто тебе помогает в программировании. Всем привет!
On 10/10/10 07:58, cgibin wrote:
> А порт на другие платформы в это начинание входит? И есть ли > какие-нибудь подвижки в этом направлении?
У нас есть подвижки, сейчас оно компилится под gcc/linux с QT-backend, однако слишком мало времени уделяем.. медленно идёт.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Может вареников под это дело сделает в конце концов 
