Начну с главного: сегодняшний Web - свалка костылей, подпорок и уязвимостей!

Для реализации современного сайта требуются: DHTML, Flash, CSS, JS, CGI, DBMS, AJAX и т.д. И вся эта разношерстная "могучая кучка" ЯП, технологий и пр. используется для получения старого унылого HTML, конец бороды которого теряется в веках. Вёрстка под разные браузеры - только с костылями. Посмотреть видео-ролик без подпорок в виде Flash-плееров невозможно. JS и CGI порождают уязвимости. Не существует ничего, что могло бы решить все эти проблемы хотя бы частично.

Поэтому я создал данную тему и предлагаю поразмыслить, пофантазировать и порассуждать о том, чем можно заменить старый унылый Web на основе HTTP/HTML, совершив революцию глобального масштаба?

Предлагаю вариант: сделать браузер интерпретатором не текста с тегами (HTML), а кода, который формирует интерфейс страницы и позволяет обрабатывать действия пользователя. За основу можно взять, к примеру, QML. Плюсы следующие:

• количество используемых ЯП, технологий и пр. сокращается до Qt/QML + DBMS + ЯП по вкусу;
• можно создавать полноценные сложные интерфейсы, ни в чем не уступающие нативным - ведь интерфейс создаётся стандартными контролами, входящими в состав фреймворка Qt;
• любая интерактивность - от элементарной анимации, решаемой средствами QML, до сложной обработки данных на стороне сервера (посредством RPC);
• любые мультимедийные возможности - проигрывание видео и аудио (достаточно включить во фреймворк нужные кодеки);
• любые 3D-модели и даже игры, причем с использованием OpenGL;
• лёгкость интеграции разнородных сервисов между собой (как задумывалось в Google Wave, только охват намного шире);
• высокий уровень безопасности - каждая страница запускается в собственной "песочнице"; цифровые подписи и любое шифрование;

И такое количество плюсов - лишь в первом приближении, навскидку! С более подробной проработкой их станет ещё больше 

Захотел страничку посмотреть - поставь Qt и g++ для начала, так чтоли ?

rsm, сегодняшний веб - это не только свалка костылей, это еще и свалка информации, оформленной с использованием этих костылей. C ней что делать?

Мы должны выпередить все капиталистические страны запада! © УССР, кто - не знаю

Это сообщение отредактировал(а) gcc - 12.1.2011, 02:45

Я же написал: сделать браузер интерпретатором <...> QML. На клиентской машине ничего кроме Qt и самого браузера не потребуется.


Полезное - переделать под новые реалии, все остальное - предать забвению. Никто и не обещает, что переход будет легким и быстрым. Однако необходимость в нем имеется однозначно.

вот есть объём информации. его надо передать. 
поясните, вы хотите чтоб на стороне клиента собралась некая браузерная "программа", закачивающая и оригинально отображающая контент? 
...аля GNU-Silverlight ?

Да кстати ... Silverlight уже создан.

{выплиил чушь}

Добавлено через 7 минут и 33 секунды

Еще раз подумав - возвращаю:

Я пральна понимаю, что новаторство идеи в том, чтобы уйти от "тонкого" клиента к "толстому"?      

Это сообщение отредактировал(а) Zloxa - 12.1.2011, 11:12

Да, что-то вроде. Браузер не HTML парсит, а интерпретирует код на QML, создавая по нему интерфейс страницы и загружая в нее контент.


Даже не рядом! Сервелат делает опять же HTML.


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

2ALL: концепцию будет легче понять если забыть о существовании HTML, JS, CSS и пр. Представьте, что вы открываете в редакторе исходный код страницы и видите там не привычную кашу из HTML и JS, а QML.

В таком случае, а не сделать ли проще? Зачем изобретать гвоздь? 
Меня уже давно раздражает подход производителей браузерных движков. Я конечно понимаю их стремление доказать крупным компаниям, что вот мол, они самые передовые, они стремятся быть на пике передовых технологий, они лучше всех, стремление это самое примитивное, подороже себя продать. И каким боком вылезает все это для веб-программиста и дизайнера? Мне приходиться использовать несколько самых ходовых браузеров в системе, чтобы каждый раз сверяться, а корректно ли работает мое приложение в этом или в этом, а как в этом или том браузере? И у меня далеко даже не сотая часть всех браузеров, что сейчас в ходу, установлена. Перечислю небольшую часть из них, ИЕ (само – собой), Макстон (надстройка над ИЕ), ФФ (огненная лиса), Опера (что и у фф, один движок), Сафари (ну, само собой), Гугле Хром (движок, что и у сафари, Апле Веб Кит). 
Из чего я исхожу, основная масса пользователей, это обычные юзеры, приходящие на твой сайт из любопытства. Первое, на что они реагируют, как твой сайт отобразиться у них в клиенте. И вот тут начинаются проблемы, каждый юзер использует свой браузер и вот подстроить свое веб-приложение под каждый браузер, из-за тех самых костылей, подпорок, очень сложно. Что в одном браузере смотрится отлично, в другом, очень коряво. Я уж не говорю о головных болях программистов. Что на одном движке просто летает, то на другом, мертво висит.
Вот и хочу сказать, а зачем гвоздь изобретать, может сделать движок, который бы объединял все новаторские предложения воедино?
Как – то несвязанно я все написал
ИМХО.  


Это сообщение отредактировал(а) Freyzer - 12.1.2011, 13:09

С чего бы вдруг? У оперы presto, у фф gecko. Первый проприетарный, второй свободный.

Проблема не в движке, проблема в головах. Едва ли не одновременно с появлением HTML появился W3C, призванный приводить внешний вид страниц к одному знаменателю путем стандартизации HTML и всех его производных. Но всегда и везде находились и находятся люди, желающие стоять поближе к включенному вентилятору при справлении естественной нужды. Сиречь, делать верстку и код, которые не соответствует вообще ничему кроме их собственного представления о том, как будет "правильно". Это первое. Далее, стоит вспомнить грустную историю Netscape vs IE. Как только на просторах Интернета остался лишь один браузер, его начали лабать как бог на душу положит, но только не в соответствии со стандартами. Такое продолжается и по сей день: если те же Gecko (движок Firefox), KHTML (Konqueror), WebKit (Safari, Chromium), Presto (Opera) реализованы худо-бедно по стандарту, то единственный и неповторимый IE гнет свою линию по принципу "сделано не у нас". К счастью, сейчас ситуация постепенно исправляется в лучшую сторону - выбор браузеров обширен. Это второе. И наконец третье: ИМХО, сами стандарты написаны настолько бестолково, мутно и "сшиты белыми нитками", что реализовать их поддержку в обозримый срок не представляется возможным; ситуация полностью аналогична С++, для которого нет ни одного компилятора, который бы на 100% соответствовал стандарту. Такие дела...

Даже если сделать один вменяемый движок, это все равно не спасет от того зоопарка разношерстных и плохо стыкующихся друг с другом приемов и технологий, которые мы имеем на сегодняшний день. Поэтому, опять же ИМХО, этот "гордиев узел" можно только разрубить одним решительным ударом, сделав по-настоящему новый Web, учитывающий существующие ошибки, недостатки, и - главное! - тенденции развития.

Спасибо за поправку, моя запарка 

rsm

Но, предложить что-то концептуально новое, да еще на голом энтузиазме? Я пессимист по натуре, я сомневаюсь в реализации нечто подобного. 

Это сообщение отредактировал(а) Freyzer - 12.1.2011, 17:36

  
как это?  

Правильно я понимаю, что мы получаем такое ж Flash/Flex или Silverlight приложение, только вместо HTML (с одним тегом embed) + swf/xap будем грузить сразу swf/xap? Ну может ещё не в бинарном виде, а текстовом - не суть. В чём профит?

Добавлено через 1 минуту и 3 секунды
HTML крут именно как язык разметки, а не язык программирования. С нехилой семантикой (в теории). Флеш/сильверлайт до сих пор (учитывая некислую историю) хреново индексируются поисковиками, а что-т новое...

И за какое время Вы собираетесь построить "новый вэб" ? 

Why бы, как говорится, и not? Многие великие проекты начинались с примитивной идеи, или просто по незнанию, или от неудовлетворенности чем-либо  Спешите приобрести наши акции "Общества гигантских растений"! 


Может у меня и скверно с английским, но HTML я пока еще отличаю от всего остального. Посмотрите направо, посмотрите налево - там мы видим канонические примеры страниц, в HTML которых вставляется объект Сервелата. Посмотрите вперед - там мы видим кунсткамеру высоких технологий, первый опыт скрещивания JS с кодом Сервелата. Обернитесь назад - там специально для посетителей вывешено описание работы Мулата, где первым пунктом идет "The web browser loads HTML, which contains ..." и далее по тексту.


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


"А там, как знать, может быть, лет через восемь в Новом Вэбе состоится первый в истории мироздания междупланетный шахматный турнир!" © почти Ильф & Петров  Если серьезно, то я пока лишь объясняю непонятные моменты и жду когда народ проникнется идеей, и начнет ее конструктивно критиковать. Вот тогда пойдет реальная работа - сделаю первый демо-прототип, напишу сервер и браузер, чтобы все заинтересованные могли пощупать живьем.

Тогда я не вижу никакого плюса по сравнению с тем, что у нас будет <embed type="application/qml" src="app.qml" />
И опять-таки - индексация уходит вникуда..

народ явно проникся "идеей упорядоченья и сокращения количества костылей", а не идеей оптимизации САБЖ. у меня есть такие заметки:


может быть я совсем плохо учился в школе, но позвольте обратить внимание на то, что всё вышеупомянутое говорит не о том, что 

а всего лишь о том, что сервилат может быть вклинен в веб-страницу как внешний объект посредствам HTML  а использование js + сервилат это уже тяжкая инвалидность.
или я чего-то не понимаю? в чём принципиальная разница между сервилатом и флешем в смысле встраивомости в веб? и тот (однозначно) и другой (в теории) могут работать без HTML. понимаю, что офтоп, но поясните на пальцах зависимость от HTML.

вот возьмём флеш, например. он конечно не собирается из QML на клиенте, но он может быть закачен и отображон в браузере без HTML (в FF проверено), имеет возможность докачки контента, его интерфейс однозначен на всех ОСях и браузерах. чем плохо, окромя проприетарности?
есть ведь целые сайты на флеш - грузишь страничку час и радуешься...

прожолжу размышления в ключе флеша. представим, что флеш стал гнутым, посылает себя в браузер не как компиленный, а как QML, который компилится на клиенте, а в браузере может единолично отображаться без HTML (в прочем, так оно щас и есть).
тогда уместной была вот эта заметка:

эта идея утопична. если каждый браузер должен будет персонально справиться с компиляцией, то компилятор наверняка у каждого будет свой. в каждой ОС кнопки и окошечки будут разные, разные шрифты итп... поэтому переход от компиленного флеша к QML флешу приведёт нас обратно к разбитому корыту.

про QT, да... там была мысль со стилями отображения формы и эта идея спасительна для вышеописанной ситуации... но вы представьте, сколько это всё будет грузится))

пока не видится мне оптимального решения...

Напомнило мне один анекдот.
Режиссер снял новый фильм про войну и перед показом Сталину показывает его Берии.
Берия посмотрел и говорит: 
- А почему усы главного антигероя так похожи на усы товарища Сталина??? Значит так! Расстрелять: режиссера, семью режиссера, актера, семью актера, сценариста, семью сценариста...
- Товарищ Берия, подождите! А может, просто актеру усы сбрить?
Берия подумал и отвечает:
- Ну или так...

Так вот я к чему... Может, просто стандарт (если он и правда невменяетмый) подправить да браузеры чуть подтянуть? Говорят, HTML5 как раз для этого и предназначен. И видео проигрывает без всяких флешей и сервелатов.

а как поисковик будет индексировать?

Предлагаю совершить небольшой экскурс в историю Web'а. Это поможет прояснить, чем вызваны и в чем состоят его основные недостатки. Итак...

1992: одна из первых публичных спецификаций HTML Tags;
1993: первое упоминание о CGI, которое мне удалось найти в RFC 3875;
1994: образование W3C;
1995: спецификация HTML 2.0, выпущенная пока еще в виде RFC;
1995: появление JavaScript;
1995: появление CGI.pm (похоже появился намного раньше, но обоснования нет) и PHP;
1995: первая версия Macromedia Shockwave Flash;
1996: спецификация на CSS;
1997: появление DHTML, в спецификацию HTML 3.2 добавлен тег <script>;
1998: спецификация на DOM;
1998: сформировался термин LAMP, предположительно с этого времени в Web'е начинают использоваться БД;
1999~2004: затишье
2005: первое упоминание об AJAX;

Очевидно, что все это - процесс перехода от гипертекста к интерактивно-мультимедийному контенту: гипертекст -> пра-HTML -> CGI -> HTML, JS, Flash -> CSS -> DHTML -> БД -> AJAX. В чем же проблема? Проблема в том, что на протяжении всего этого времени HTML практически не изменился! По-идее, его следовало бы радикально пересмотреть еще на этапе появления CSS, который является ни чем иным, как костылем, позволяющим расширять убогие теги HTML дополнительными стилями. При появлении DHTML следовало бы радикально пересмотреть HTML еще раз, с учетом возможности внедрения объектов (Flash) и задумавшись над слиянием CGI и JS в нечто целое, позволяющее управлять содержимым страницы со стороны и клиента, и сервера. Однако ничего из этого сделано не было и из JS получился замечательный костыль под названием AJAX. А из РНР - много бесталанных проектов и посредственных программеров.

Возвращаясь к вопросу, заданному в цитате ("не вижу никакого плюса по сравнению с тем, что у нас будет <embed type="application/qml" src="app.qml" />): HTML должен умереть! Навсегда и в страшных муках. Ибо вставка кода QML внутрь HTML порождает еще одну подпорку, а не решает все обозначенные в первом посте проблемы.


Про инвалидность - полностью согласен. Однако все же программа Сервелата может влиять на HTML именно через JS (пример) или даже напрямую, без JS (пример). А коли потенциально такая возможность есть, то обязательно будут и те, кто ею воспользуется. Все покатится по накатанной дорожке - у HTML появится еще один новый передовой красивый костыль со звучным названием.


Да, может. Но есть несколько проблем:

• избыточный объем;
• откровенные тормоза на отрисовке;
• возможности по созданию интерфейсов сильно уступают Qt;
• нет стандарта(ов) на внешний вид контролов (кнопки, ниспадающие списки и пр.);
• в силу работы на виртуальной машине есть сложности со взаимодействием с железом и БД;

И наконец, я ни разу не видел ни одного сделанного целиком на Flash корпоративного или публичного SaaS. Может быть просто не повезло, буду признателен за примеры.


А долго создаются виджеты когда их таскают в Qt Designer? 


Можно и так. Разница, правда, не слишком велика, т.к. стандарт придется переделывать чуть более чем полностью. Потому, что гипертекст сейчас никому не нужен, нужен интерактивно-мультимедийный контент. Для которого HTML подходит менее всего. Был бы сейчас 1995-й год - еще можно было бы что-то предпринять. А сейчас остается только закопать.


Еще один маленький, но приятный костыльчик; классический пример скрещивания теплого с мягким - встраивание видео в язык разметки гипертекста.



Первая конструктивная критика! Что делать с поисковиками, я пока не придумал. Для начала, надо представлять, как они работают. Возьму на заметку 

Ты просто смотришь на веб - исключительно как на приложения. А не как на контент. Что касается поискоивков - при таком подходе они обречены.

Я писал, но повторюсь - хтмл крут ни как платформа для приложений, а как язык рамзетки контента.

Это сообщение отредактировал(а) Любитель - 13.1.2011, 14:35

мы же как-то читаем, пусть учатся

Ну действительно..
HTML придуман как формат для контента! В нём (теперь) есть оооч много вещей для семантичной разметки. QML придуман совсем не для этого. Сответственно - очевидно, там этого нет.

rsm, хорошо. Давай конкретику. Давай, скажем, пример сайта с картинками. В качестве вдохновения - flickr.com

IgorIV, есть проги, которые в фотках находят фразы... не помню как называется, что-то со слоном связано было))) но есть! в конце то концов, пора уже заняться распознанием образов и речи! трактористы мастдай!

Добавлено через 3 минуты и 18 секунд
вообще, тема актуальная, сложная и один человек её не поднимет. да и вообще, с виду неподъёмная тема

А он именно таким и стал. Кому сейчас интересен голый статический гипертекст?


Если контент статический текстовый - да, что-то хорошее в HTML'е есть... Хотя реализация таблиц, к примеру, мне все равно не нравится - недаром сайты, где их много, так тормозят.


Я привел в пример QML как идею, как один из вариантов реализации. Это вовсе не означает, что итоговый проект будет именно на Qt/QML. Важна концепция: кросплатформенный фреймворк для отображения контента и интерпретируемый код для реализации загрузки контента и обработки действий пользователя.


Может, не будем торопиться и сперва худо-бедно скумекаем, что как делать, а уже потом кинемся на приступ с компилятором наголо? Прототип будет. Но не сейчас, когда все находится на уровне идей и концепций. Да и те еще не до конца проработаны, та же индексация - уже весьма интересный вопрос.


Вот для этого и нужны форумы 

А компилятор не нужен. Покажи именно идею, как ты её видишь. Вот хотя бы и на Qt. А натрепатся можно до чего угодно. Вот только человек существо очень консервативное. 
На протяжении более ста лет в конструкцию автомобиля не внесено принципиальных изменений. Те же 4 колеса, двигатель (бензиновый!!!), руль, тормоза и т.д. 

Флеш? 

Т.е. браузер и сервер предлагается писать на Logo?


В виде чего? Сайта? Ты его уже видишь когда читаешь этот текст. Я - за революцию в технологиях, а не в дизайне.


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


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

В полную противоположность тому, от HTML'а с друзьями (CSS, JS и т.д.) хотят получить все и сразу. Хотя в действительности область применения HTML весьма ограничена - разметка гипертекста. И все! Когда мы начинаем возлагать на HTML несвойственные ему задачи типа внедрения тегов на объекты Flash'а, мы тем самым пытаемся сделать из "легковушки" танк. И беда в том, что некому нам покрутить пальцем у виска, сказав "что ж вы делаете, злыдни, это ж костыль на костыле костылем подпирается, и никогда вы не сделаете танк из легковушки - выбросьте ее и начните с нуля!".

Так что сравнение как минимум неудачное. Автомобиль не менялся только потому, что ему, в отличие от HTML'а, никто, будучи в здравом уме, не пытался приклепать одновременно гребной винт, реактивный двигатель и двуногую шагающую платформу.


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

Ясно. Ничего конкретного, чтобы пощупать ты предложить не можешь.

смешной вывод... после двух страниц жаркого обсуждения))))))

TC, я надеюсь, ты понимаешь что придётся писать свой движок с браузером, что бы ты ни изобрёл? или как минимум двиг + плагин к существующему браузеру... я надеюсь, ты так же понимаешь, что для демонстрации нового веба придётся еще и сервак поднять, ибо стандартные серваки новым требования отвечать не будут...

...но это лирика)))
я так и не услышал ответа по поводу реализации универсального клиентского движка:

1) в частности меня интересует, планируется ли в условиях данной концепции создание нового браузера, понимающего новый веб (или это будут костыли-плагины к существующим)?

2) если да, то как вы расчитываете выдержать конкуренцию в этой области с существующими браузерами? ведь за один день на новый стандарт все разом не перепрыгнут...

3) для написания кросовых браузеров и движков придётся полюбасу писать описание стандарта. это описание, как и описание HTML все будут реализовывать по-своему, в кривь и вкось. то есть возвращаемся к проблеме, с которой начали - как заставить всех выдержать стандарт и сохранить единство интерфейса?

 объём проблем настолько гигантский, что ИМХО вы сполна оправдываете свою подпись под аватаром   

Разработка мне дается легче проектирования, иначе б этой темы тут не было. Браузер и сервер будут писаться с нуля.


Сервер (как таковой, железо) у меня уже есть и работает.


Так же, как ее выдержал TCP - простота, эффективность и технологичность 


Никак, это невозможно в принципе. Да и не нужно, ведь многообразие способствует эволюции.

многообразие способствует тому что хтмл в опере, ФФ и в ИЕ выглядит по-разному   

Я подразумевал многообразие браузеров. Проблему унификации интерфейса страниц решает фреймворк.

rsm, придумал свой Java Web Start/ClickOnce/Zero Install с блэкджеком и шлюхами 

Не вижу никакой связи 
Предлагается каждый сайт устанавливать в виде отдельной программы? Подход интересный, но народ вряд ли оценит. Хотя... Для любителей одноглазников и контактега будет в самый раз, они все равно не подозревают о существовании иных ресурсов 

Ну да, не устанавливать, а скачивать во временную директорию и через некоторое время удалять - это конечно принципиальная разница  

CompWorm, понимаешь, если человек что-то предлагает публично, значит он уже это всё обдумал и разложил по полочкам, по крайней мере для себя. Сделал какой-никакой прототип. Нашел недостатки, достоинства.

Продолжим. Гипертекст никому не нужен.
http://imagemagick.org/script/index.php
http://sysoev.ru/
http://avisynth.org.ru

Не видел сайтов на флеше
http://www.nissan.ru/
http://www.adidas.com

Далее, интерпретатор кода.
qmlviewer.exe подойдет на эту роль?
Позволяет просматривать qml-файлы. Вот тебе и flickr 
http://doc.qt.nokia.com/4.7-snapshot/demos...ive-flickr.html
И вот что получается
http://labs.qt.nokia.com/2009/05/13/qt-declarative-ui/

Это наше будущее?

Добавлено через 1 минуту и 19 секунд
Вот что у меня получилось

Присоединённый файл ( Кол-во скачиваний: 7 )
 flickr.7z 937,21 Kb

Тоже, конечно, вариант, но очень уж примитивный. Да и слабо представляю нормальный интерфейс на Java чтоб не тормозил, особенно на смартах и КПК с малым количеством оперативки 


Особенно порадовала первая ссылка, заканчивающаяся на *.php. Ни один из приведенных примеров не является чистым гипертекстом, даже на спартанском sysoev.ru присутствует CSS.


Спасибо за примеры!  Которые так ярко показывают все названные мною выше недостатки. Теперь я знаю, что бывают сайты целиком на Flash, и все они - ужасны.


Если его чуть более чем полностью переписать - то вполне подойдет. Ему не хватает движка reST'а. А так же встраивания произвольных виджетов типа видеоплеера, и самих виджетов. И еще разделения страниц в "песочницы". И еще передачи данных по STCP. И еще расширения QML'я возможностью обращения к БД. И еще много чего другого. Сущие мелочи, право слово!


Да, примерно такое  Только лучше и в нем можно будет грабить корованы 

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

Ты просто не задавался вопросом поиска сайтов на флеше, для этого было достаточно 5 минут. Ты заранее решил, что он плохой и все.

Ну так дерзай. 

Я видел самые ранние сайты целиком на Flash'е и очень надеялся, что сейчас они стали хоть немного лучше. Оказывается, не стали.

2ALL: появилась идея по поводу индексации. Что если выделить для текста виджет определенного класса? Это все равно придется делать, т.к. страница будет представлять собой набор виджетов, отрисовывающих картинки, Flash и пр. Поисковый робот будет запрашивать страницу и индексировать текст из всех виджетов заданного класса. По-моему, вполне себе решение.

Еще задумался, как обеспечить прозрачную работу с БД. Может быть взять за основу не QML, а что-нибудь типа Python? И тогда страницы будут представлять собой код на Python + интерфейс на Qt. Вот уж где будут безграничные возможности по наворачиванию функциональности! Т.к. фактически страница будет представлять собой полноценную программу. Тогда и доступ к БД решается легко - достаточно будет разделить код на две части: серверную и клиентскую. Серверная часть представляет собой класс, инкапсулирующий все обращения к БД, включая авторизацию, которую совсем даже не надо показывать клиенту из соображений безопасности. Клиентская часть будет работать только с классом, предоставленным сервером. Это будет способствовать не только простоте расширяемости, но и изначально грамотному проектированию и разделению программы по MVC.

Таким образом, приходим почти что к идее, предложенной LSD - сайты как программы. Только еще более глобально: операционная система, для которой не будет принципиальной разницы, установлена программа локально или загружена с сервера. А браузер станет лишь проводником в мир, позволяющим искать нужные ресурсы. OMG, я только что выдал свой замысел о мировом господстве! 

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

Каким тегам? В секции <meta>? А их кто-нибудь вообще юзает? Разумеется индексация будет по всему тексту.

Вначале введём виджет "контента". Затем захотим семантики - введём виджеты для парагрфов, заголовков и т. д. Захотим отделения контента и стилей - введём CSS (впрочем, в Qt в урезанном виде он уже есть, хотя не в курсе как там в случае QML). Мне кажется, что мы переизобретаем HTML/CSS/JS 


Да. Все поисковики и сайты, заботящиеся о поисковиках. Другой вопрос, что в случае "сильного несогласования" прочего контента и кейвордов в метах, поисковик будет недоволен..

Романтиииик 
Ты всё ещё думаешь? Когда делом займешься?
Знаешь в чем преимущество гипертекста?
Ты сейчас на форуме программистов, щелчок по этой ссылке и ты через 5 секунд видишь мой маршрут до работы.

Ты знаешь, он давно им стал.

ОК, тогда может быть вообще пересмотреть формат представления информации на сайтах? Например, почему бы не использовать SVG? Векторный формат, исходники в XML, его достаточно легко парсить, назначать события на действия пользователя. Не будет проблем с мелкими экранами и любыми, даже самыми извращенными оформлениями текста. Хотя тормозить все это будет ужасающе...


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


А я где-то предлагал искоренить идею URL? Не нужно путать теплое с мягким.


И пробыл ровно до того момента, покуда в нем не появилась поддержка JS, Java-апплетов и Flash'а. Ибо с этого момента браузер стал не только (и не столько) проводником в мир, но еще и средой выполнения никоим боком не относящихся к HTML'у вещей.

Ну.. Сорри, если я пропустил сарказм, отвечаю серьёзно.
SVG - это всё ж графика. Да, векторная графика и, как следствие, есть блоки текста. Но семантики нету никакой. А так - в принципе SVG тоже развивается в рамках "стандартного стека веб стандартов"..

ИМХО, большинство сайтов настолько гламурненькие, что векторная графика пошла бы им только на пользу. Хотя делать всю страницу одной картинкой, наверное, все-таки перебор... Тогда другой вариант - TeX. Это уже настоящая система настоящей верстки. И тоже, кстати, в чисто текстовом виде. А значит - прекрасно индексируется.

Может QT, а может Python, а может SVG - ты ещё так и не понял. Есть пословица - начало полдела откачало. А ведь ты даже и не начинал дело, всё думаешь. А что такое человеко-год по сравнению с избавлением миллионов людей от существующего ига HTML и иже с ним? Песчинка в пустыне.
Если бы мне было совсем неинтерсно, что у тебя получится, я бы в теме не отписывался.
Проясни вопрос с безопасностью. Скажем условный синтаксис, ведь этот браузер будет полностью использовать ресурсы железа.

Да, я еще не понял. Возможно, это потому, что я слабо представляю потребности среднего юзверя в вакууме - мне лично более чем хватает чистого HTML, без приправ в виде AJAX, Flash и прочего. Однако народу надо градиентные заливки фона, самые невероятные шрифты и верстку, побольше ссылок на YouTube и побольше игр на Flash. А может быть и еще чего-нибудь странного, о чем я даже не догадываюсь, будучи взращенным на сайтах начала 00-х и унылом модемном коннекте.


А мыслительный процесс уже не считается делом?


Да в принципе ничего нового и передового - "песочницы". Бытует мнение, что браузер Chromium реализует их для каждой страницы. Хочу сделать так же. Страница работает в отдельном процессе и юзает свою независимую виртуальную файловую систему (chroot).

Тобиш, я должен тянут с сервера к каждому новому сайту, на который я перехожу свой файловый набор в кеш, для того чтобы просмотреть данный сайт, типо того ?

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

Никого не хочу обидеть, но тема похожа на: человек познакомился с технологией и подумал....

по теме: есть Java FX

Мёртворождённая.

Но на самом деле есть куча технологий, вопрос всё таки в том, что мы хотим достичь. Основного поинта и преимущества перед суещствующими технологиями  я пока не понял.

Сходи в салон сотовой связи и попроси показать телефоны на Android  




1. Я не говорил про Java. Я привел примеры 3-х технологий которые похожи на твою идею (они не в точности ее повторяют, но похожи) и только одна их них была Java.
2. Такая система уже есть (бета версия). Угадай с 3-х попыток как она называется? 
3. Проблема с твоей концепцией прежде всего в безопасности. Давать приложению возможность "выбираться" за пределы браузера, будь-то кнопки за пределами окна или доступ к файлам, и цифровые подписи проблему не решал. Вспомни тот же ActiveX, тоже нативный клиент, те же цифровые подписи, разве что без Qt и IE only, в остальном это то, о чем ты пишешь.

Как показывает практика, самые каверзные вопросы ухитряются задавать как раз новички, не принимающие установленных правил игры "аксакалов". Я не понимаю, в чем профит от той свалки костылей и подпорок, которой сейчас является Web?


Хотим достичь единой технологии/подхода создания Web-ресурсов. Что имеем сейчас:

• HTML - текстовый контент с разметкой;
• CSS - стили для текстового контента с разметкой;
• JS - управление DOM'ом;
• DHTML - интерфейс, создающий DOM и обработчики событий;
• AJAX - асинхронное управление DOM'ом через JS;
• CGI - интерфейс взаимодействия "клиент <=> сервер", "клиент <=> БД";
• ????
• УЖАС!!! 

Что хочется получить:

• ??? - нечто, заменяющее собой все перечисленное;

Владелец HTC Hero. Java тормозит 


Первая - Java. Вторая - проприетарщина, недопустимая для Web'а даже теоретически. Третье - довольно-таки кривой способ установки софта. В общем, выбирать было не из чего.


Plan 9? i2p? Гипертекстовый Векторный Фидонет?


Не надо ему давать такую возможность. Пусть сидит в своей "песочнице" и никуда за ее пределы не лезет.

Прочитал.
Проникся.
Согласен.
Но.

1. Давайте до кучи пересмотрим HTTP - не менее дряхлый, хотя бы потому, что современность жаждет двухсторонней иннициации подключения, а не односторонней, как сейчас. Масса левых наворотов предназначены только для того, чтобы обойти нынешнюю парадигму.

2. Сдается мне, не нужно огульно все отвергать. Есть ведь и масса продуманных вещей. Ну сделаны через жопу, с кем не бывает...

Поэтому предлагаю двигаться от обратного: берем что есть и отсекаем лишнее   
Кроме того, то, что я почитал вначале (про Qt etc) чем-то здорово напоминает мне XUL...

Не то?

А вообще тенденция такая наблюдается уже давно - привести фарш из разметки, ксс и скриптов к чему-то строго-изящному на базе xml, что уже полноценно разворачивается на клиенте.
Сдается мне, разумнее исследовать именно эту тему, прежде чем разрушать до основания. Хотя топикстартера понимаю, руки порой очень даже почёсываются.

Т. е. вместо разделения серверной части, данных, представления и логики взаимодействия получить технологию для толстого клиента, где всё свалено в кучу? Сорри, но выглядит именно так. Классический стек веб технологий не идеален, но далеко не так плох, как ты патешься его изобразить..

Не проприетращина, а стандарты ECMA C# and Common Language Infrastructure Standards  




Chrome OS как раз и идет по пути реализации этой идеи. Правда технологии выбраны не те, за которые ты выступаешь.




А как реализовать:



при этом, не давая приложению вылезать за границы окна (OpenGL), без доступа к системным библиотекам (системные кодеки) и файлам (сохранение документов)?

Ну, теоретически есть даж всякие Google Native Client.. Но реально я это не щупал.

Всё придумано до нас.

??????????
Ты реально так думаешь, что все идет так последовательно?
У меня Опера показывает начало страницы, когда окончание страницы еще не загрузилось.

Мне захотелось прояснить вопрос о тормознутости флеша, в чем это выражается?
И второй вопрос, что думаешь насчет WebGL?

Непременно  Предлагаю STCP.


Согласен, что по отдельности вещи хороши. Проблема в том, что их пытаются объединить.


Да, тоже вполне себе! Однако это опять-таки соединение XML + JS - немногим лучше, чем HTML + JS.


Если концепция "сайты как программы" выгорит, то разделение по MVC станет вполне возможным - чуть выше я приводил пример, когда клиент работает с классом, реализующим доступ к БД.


Стандарты под честное слово? Очень характерный типаж, я даже начинаю смутно догадываться, чье именно изобретение этот "си-за-решеткой"... 


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


Так же, как это реализовано в виртуальных машинах. В том же VirtualBox в полный рост есть поддержка 3D-графики. А в qemu так и вообще - проброс железа хоста внутрь гостевой системы. Сохранение файлов можно реализовать специально выделенной, единой для всех страниц виртуальной ФС, откуда их легко будет выгрести.


Главное - в том, что для корректного отображения всей страницы браузер должен скачать ее целиком. Я отвечал на именно такой вопрос, а не разъяснял особенности внутреннего устройства механизма загрузки страниц - ясное дело, что любой нормальный браузер огранизует многопоточную загрузку и пытается как можно быстрее распарсить и отобразить скачанные кусочки. Однако "чуть-чуть - не считается!", как говаривал старина Хоттабыч (не путать с созвучным мастдайным трэш-фильмом!).


В загрузке процессора на 100% и жутких тормозах анимации. Хотя, конечно, Atom 230 (1,6 ГГц) - это даже не смешно, куда мне смотреть Flash с таким старьем!


Идея интересная, но если верить Вике:


то WebGL - не более чем еще один костыль для многострадального HTML.

Мне просто непонятно, почему современные "классические" АПИ (JS апи, базирующиися на DOM и пр.) тебе не угодили. HTML всегда был лучшим (за отсутствием серьёзных альтернатив) языком разметки контента. CSS - один из лучших языков (да, многого не хватает, но лучшии решения существуют, на мой взгляд, лишь как обёртки над цсс) для "оформления". JS - вполне себе хороший/удобный язык. HTML5-ные АПИ нацелены именно на то, чтоб предоставить более продвинутый АПИ для приложений...

Я, конечно, не берусь навязывать своё мнение, но при всей массе минусов, этот набор технологий очень хорош.

Это все вопрос желания "сообщества" делать свою реализацию. Если бы тот же Гугл сделал свою отрытую реализацию .NET (или стал активно поддерживать Mono) и замутил совой Silverlight, то .NET мог бы стать стандартом для WEB.




Формально - это не обязательно. Но смысла использовать WEB приложение и не использовать облачные сервисы - немного.




Жесть, вместо простого браузера ты предлагаешь замутить целую виртуальную машину. А как эта вся фигня будет чувствовать себя на смартфонах где Java тормозит?

Тем, что их слишком много и они плохо состыкованы. Каша в технологиях порождает кашу в головах.


Если верить Вике, стандарты на С# появились 5 лет назад. В то же время запустили проект OpenJDK. Спрашивается: почему за прошедшие 5 лет OpenJDK стала вполне юзабельной, а вариации C# так и остались на уровне, слабо отличимом от "Hello, World!"? Где разработанные по стандартам решения для мобильных платформ? Не иначе это заговор? Нехороший дядя RMS всех запугал?


Не мог бы по причине тяжелой наследственности. Стандарты - стандартами, однако никто не мешает оффтопику выпустить следующую версию Пончика с "недокументированными возможностями", которые быстро уйдут в мэйнстрим. В результате чего все, кто юзает "альтернативные" вариации, дружно отправятся в известном направлении. В общем, скатываемся в войнушку Java vs Пончик...


Тогда может быть все же "сайты как программы"? Раз среднему сферическому юзверю в вакууме нужны "облака", пусть радуется с комфортом?


Полагаю, что без проблем - предполагаемые "песочницы" будут достаточно легковесными, т.к. их функционал будет ограничен.

Хорошо, я понял. Спорить не буду особо (мы же ещё не в холиварах?), но моё мнение, что это как раз хорошее разделение обязаностей и хороший стек технологий. Исторические проблемы есть (а как же без них?), но впечатление в целом - очень даже положительное.


Ну, если брать современные мобильные платформы, то из настоящих (поддерживаемых не только энтузиастами) универсальных решений - как раз только вебовые клауд приложения (хотя тут как раз есть проблема с ИЕ, но всё ж).


А зачем? Если речь про дотнет и веб, то МС были б (в своё время) просто нереально рады, если б сильверлайт получил действительно распространение (в сфере "обычных" веб приложений). Этого не случилось и сейчас они пытаются доказать (смотрим все статьи по ие9), что "мы хотим продвигать HTML5 и пр". И, даже более того, если взять прошлые версии ие и 9-ку, то отрыв в пользу "классических решений" действительно очень большой.


Если я правильно прочитал, то там фраза была, что "если веб-приложения, то клауд-сервисы". Ты либо перевернул эту фразу, либо я чего-т не понял.

Можно немного поподробнее раскрыть тему? Скажем, на примере формы отправки комментария в блог. Как тебе представляется вся цепочка действий? Я себе представляю примерно такую карусель:

• код на JS обработчика действия "onclick" кнопки проверяет совпадение контрольного кода (capcha);
• в случае совпадения проводится переадресация на некоторый URL, допустим "server/comment.php?is_code_valid=true";
• браузер выполняет переход на этот URL;
• http-сервер прогоняет скрипт comment.php через интерпретатор PHP;
• код на PHP запрашивает значения переменных $_GET и $_POST (могу ошибаться в названии, PHP юзал очень давно);
• код на PHP получает значение GET-переменной "is_code_valid=true" и принимает решение добавить комментарий в БД на MySQL;
• код на PHP подключается к БД, авторизуется, берет значение POST-переменной "comment_text", содержащей текст комментария, добавляет в БД новую запись и закрывает соединение с БД;
• код на PHP непосредственно генерирует или берет из шаблона HTML-код текста "Ваш комментарий успешно добавлен";
• http-сервер отправляет браузеру HTML, сгенерированный кодом на PHP;
• браузер парсит HTML, накладывает на него CSS и отображает;

А теперь представим, что было бы, используй мы некий язык Х и фреймворк:

• код на Х обработчика действия "onlick" кнопки проверяет совпадение контрольного кода (capcha);
• в случае совпадения, код на Х выполняет следующие действия:
• устанавливает соединение с БД, авторизуется, добавляет в БД новую запись с текстом комментария, взятым из виджета, и закрывает соединение с БД;
• выводит в виджет текст "Ваш комментарий успешно добавлен";

Какой вариант быстрее, проще, прозрачнее и технологичнее?

ИМХО, ситуация как со средствами RAD, которые часто (и заслуженно!) обвиняют в том, что они отучают думать. Т.н. "программист" тупо раскидывает кнопочки по форме, не представляя даже приблизительно, какая прорва кода за всем этим стоит и как это работает хотя бы в первом понимании! Здесь все аналогично. Что делает средний "программист" на PHP в вакууме? Берет какой-нибудь там Symfony, берет RAD типа Aptana Studio и ваяет "Страницу Крутого Вована, главного кореша Крутого Коляна". И, как ни странно, все работает! Я ни в коем разе не осуждаю подобных "программистов" и уж тем более тех, кто зарабатывает на жизнь Web-разработкой, в т.ч. реально толковых PHP'шников! Я лишь хочу подчеркнуть, что бОльшая часть людей даже приблизительно не представляет, какой чудовищный бардак из костылей и подпорок творится "под капотом" тех фреймворков, RAD и прочих средств, которые они используют. Такое вот скверное положение дел и подтолкнуло меня к созданию этой темы.


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

если у Вас не жополизный менталитет, то самое главное:
1) чтобы это работало
2) чтобы приносило деньги

г*вно будет и так, и так  © 
 
===

• для Captcha, есть reCaptcha от google
• отправлять на сервер данные можно в json вместе с объектами которые будут использоваться на сервере, парсер json быстро десериализирует и не будет тратить ресурсов на инициализацию объектов и структур на сервере
• отправить обратно на клиент ответ в json (0.0008s)
• соединение можно держать открытым... (максимум 1 соединение)

ЗЫ: если бы это делать для: нового ЯП (допустим), больших нагрузок или как аналог Skype... - то можно понять

Это сообщение отредактировал(а) gcc - 19.1.2011, 03:27

Вот, значит, как теперь называют стремление писать надежный качественный софт?


Т.е., используя JS, можно передать произвольные данные в код на PHP, не перезагружая страницу - я правильно понимаю?