Здравствуйте, Sinclair, Вы писали:

S>Кстати, в gmail встроен вьювер PDF-ов, который работает без Adobe. Так что откладывать твой "другой разговор" некуда.
Ну или если совсем некуда деваться — https://github.com/mozilla/pdf.js

Здравствуйте, Sinclair, Вы писали:

PD>>Вот это , конечно, шаг на пути к полноценному приложению. Только вот чем он реализуется, этот просмотр виде (я не силен в HTML5). Если самим HTML (кодом в нем) — это одно, а если просто броузером — тогда мы имеем прежнюю ситуацию.
S>Не очень понятен вопрос. В HTML никакого кода нет. Весь просмотр чего угодно реализуется "нативным кодом обеспечения".

В HTML непосредственно когда, конечно, нет. Но есть встроенный туда js, он и есть код. Или код ActiveX, или код для flash-player. Вот это и есть код web-приложения (на клиентской стороне).

PD>>Антон, ты просто плохо понимаешь устройство Windows.
S>Нет, Павел, это ты плохо понимаешь устройство Web. Поэтому нерелевантный ликбез поскипан.

Увы, это ликбез необходим. Аргументов у тебя не нашлось. Если я плохо понимаю, как из web-а печатают — OK, расскажи. Вот в web-приложении (страница, открытая в броузере) код js или чего-то еще мне там пункт меню Print нарисовал) я этот пункт меню выбрал и ... что дальше ? Расскажи, хотя бы в применении к Windows, этого вполне достаточно.

PD>>Ну а в данном случае просто броузер берет на себя вызвать эти функции. Больше некому
S>Это всё очень хорошо, но с точки зрения практики, это означает, что все рассуждения про "недоступность печати для веб приложений" — малоинтересная ерунда.

Не передергивай. Где я говорил про недоступность ? Не было такого! Я говорил, что реализует ее нативный код.

>Веб приложению недоступен WinAPI, а вот функции печати — вполне себе доступны. Если есть какие-то сомнения — сходи купи билет хотя бы на аэроэкспресс, и убедишься, что никаких проблем с печатью там нет.

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

PD>>Нет, не пойдет. Речь не о процессоре. а о web-приложении. На твоем любимом дотнете в конечном счете выполняется нативный код, но это же не мешает тебе говорить о программе на дотнете, на C#, а за скобками держать JIT. А уж явисты некоторые вроде как и впрямь уверены, что ниже JVM ничего нет. Так что это не аргумент.

PD>>Вот когда код страницы, загруженной в броузер, будет все сам делать (видео исполнять, pdf открывать без Adobe, doc открывать без Word или OO и т.д.) — вот тогда другой разговор будет.
S>Ничего не понимаю. Что такое "сам"? Что такое "код страницы"? Если уж джавистам можно игнорировать мир ниже JVM, то веб-девелоперам тем более можно забить на то, каким именно образом реализован тег <video> или тег <canvas>.


Код JS или ActiveX или flash. В общем, код, пришедший с сервера. Код, который загружается в исполняющую среду.


S>Кстати, в gmail встроен вьювер PDF-ов, который работает без Adobe. Так что откладывать твой "другой разговор" некуда.

На этот раз я не понял. То есть я могу не устанавливать Adobe и смотреть на своей машине pdf ? И при чем тут gmail ?

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>В HTML непосредственно когда, конечно, нет. Но есть встроенный туда js, он и есть код. Или код ActiveX, или код для flash-player. Вот это и есть код web-приложения (на клиентской стороне).
Ок, хорошо.

PD>Увы, это ликбез необходим. Аргументов у тебя не нашлось. Если я плохо понимаю, как из web-а печатают — OK, расскажи. Вот в web-приложении (страница, открытая в броузере) код js или чего-то еще мне там пункт меню Print нарисовал) я этот пункт меню выбрал и ... что дальше ? Расскажи, хотя бы в применении к Windows, этого вполне достаточно.
Дальше у тебя на экране оказался диалог печати, предоставленный браузером. Там ты проводишь платформенно-специфичную настройку параметров печати, и предоставленный веб-приложением контент уезжает на принтер. Пересекая, при этом, несколько уровней абстракции.
Вариантов этого процесса очень много, далеко за пределами форумного поста. Главное — что с точки зрения разработчика веб-приложения, всё это могут с тем же успехом делать офисные гномы. Его работа закончилась на подготовке контента для печати.


PD>Не передергивай. Где я говорил про недоступность ? Не было такого! Я говорил, что реализует ее нативный код.
Цитирую:

Кстати, если уж говорить о Web — надо, чтобы все реализовалось средствами web

Ну и далее про нативный драйвер. Я, наверное, не так понял — но откуда взялось вот это требование "чтобы всё реализовывалось средствами web"?

PD>А апелляция к практике не годится. С точки зрения пользователя он (пользователь) нажимает клавиши, а на экране печатаются буквы и цифры. Почти так же, как на пишущей машинке. И ты его в этом не переубедишь. Но , надеюсь, ты понимаешь, что связь между этими двумя эффектами очень даже опосредованная. Вопрос же не в том, что думает об этом пользователь, а о том, что там в действительности.
Вопрос, "что в действительности" сам по себе смысла не имеет. Всегда найдётся ещё один уровень абстракции, заглядывать в который мы не стали. С точки зрения программиста, интересен вопрос о том, сколько и каких усилий нужно приложить лично ему, чтобы получить нужную функцию.
Ну так вот разработчики Windows-приложений уже двадцать с лишним лет не пишут свои драйвера принтеров. У них есть некоторая абстракция, которой они пользуются. Так и разработчики веб-приложений не пишут свои драйвера принтеров, а пользуются готовой абстракцией.

PD>На этот раз я не понял. То есть я могу не устанавливать Adobe и смотреть на своей машине pdf ? И при чем тут gmail ?
Именно, что можешь смотреть на своей машине pdf безо всякого Adobe. А Gmail — это такое малоизвестное веб-приложение, оборудованное этой возможностью. Добро пожаловать в реальный мир.

Здравствуйте, Sinclair, Вы писали:

S>Ок, хорошо.

PD>>Увы, это ликбез необходим. Аргументов у тебя не нашлось. Если я плохо понимаю, как из web-а печатают — OK, расскажи. Вот в web-приложении (страница, открытая в броузере) код js или чего-то еще мне там пункт меню Print нарисовал) я этот пункт меню выбрал и ... что дальше ? Расскажи, хотя бы в применении к Windows, этого вполне достаточно.
S>Дальше у тебя на экране оказался диалог печати, предоставленный браузером. Там ты проводишь платформенно-специфичную настройку параметров печати, и предоставленный веб-приложением контент уезжает на принтер. Пересекая, при этом, несколько уровней абстракции.

Вот именно, что пересекая.

Диалог выведен с помощью DialogBox или ее аналогов. Вывел его браузер. Настройку печати браузер не может делать, не его это уровень. Диалоги настройки выводит ПО принтера. Потом все же StartDoc , TextOut и т.д., потом EndDoc, вызываемые браузером. А браузер — не часть web-приложения. Так что печатает не web-приложение, а его исполняющая среда.


S>Вариантов этого процесса очень много, далеко за пределами форумного поста. Главное — что с точки зрения разработчика веб-приложения, всё это могут с тем же успехом делать офисные гномы. Его работа закончилась на подготовке контента для печати.

Да могут в принципе. кто же спорит. Добавьте в JS вызов этого диалога и пусть интерпретатор JS его вызывает. Криминального тут ничего нет. вызывает же его код на C# через свои классы. Вот и пусть js выхывает, а интерпретатор js компилирует (интерпретирует) этот вызов и показывает диалог.

Это никому не нужно, скажешь ты. Правильно, не нужно. Это вообще бессмысленно, так как проще переадресовать это среде исполнения. Не спорю. Но я просто фикисровал факт — web-приложение большей частью требует нативного кода исполняющей системы.


PD>>Не передергивай. Где я говорил про недоступность ? Не было такого! Я говорил, что реализует ее нативный код.
S>Цитирую:
S>

S>Кстати, если уж говорить о Web — надо, чтобы все реализовалось средствами web

И где тут про недоступность ?

S>Ну и далее про нативный драйвер. Я, наверное, не так понял — но откуда взялось вот это требование "чтобы всё реализовывалось средствами web"?

Тут просто твое непонимание того, что мы обсуждаем. Я изначально просто две вещи сказал : что web-приложения примитивны пока что, и что они опираются на нативный код, то есть в действительности большая часть их возможностей обеспечивается отнюдь не web-кодом. Требования такого вовсе нет, естественно, просто есть констатация факта — в собственно web-коде делается на клиенте очень немного, большая часть — в нативных приложениях/модулях.

PD>>А апелляция к практике не годится. С точки зрения пользователя он (пользователь) нажимает клавиши, а на экране печатаются буквы и цифры. Почти так же, как на пишущей машинке. И ты его в этом не переубедишь. Но , надеюсь, ты понимаешь, что связь между этими двумя эффектами очень даже опосредованная. Вопрос же не в том, что думает об этом пользователь, а о том, что там в действительности.
S>Вопрос, "что в действительности" сам по себе смысла не имеет. Всегда найдётся ещё один уровень абстракции, заглядывать в который мы не стали. С точки зрения программиста, интересен вопрос о том, сколько и каких усилий нужно приложить лично ему, чтобы получить нужную функцию.

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

S>Ну так вот разработчики Windows-приложений уже двадцать с лишним лет не пишут свои драйвера принтеров.


Опять ты демонстрируешь непонимание. Не то, что не пишут, а не могут писать. Драйвер в нулевом кольце исполняется, а разработчикам приложений под Windows (NT линии) туда хода нет.

У них есть некоторая абстракция, которой они пользуются. Так и разработчики веб-приложений не пишут свои драйвера принтеров, а пользуются готовой абстракцией.

PD>>На этот раз я не понял. То есть я могу не устанавливать Adobe и смотреть на своей машине pdf ? И при чем тут gmail ?
S>Именно, что можешь смотреть на своей машине pdf безо всякого Adobe. А Gmail — это такое малоизвестное веб-приложение, оборудованное этой возможностью. Добро пожаловать в реальный мир.

Лучше ссылку дай, тогда и последую. Для меня Gmail — это только почта, остальное проходит как google.com. У меня на виртуалке как раз никакого pdf-вьюера нет. Давай ссылку, попробую и пойду в реальный мир в малоизвестные приложения.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Диалог выведен с помощью DialogBox или ее аналогов. Вывел его браузер. Настройку печати браузер не может делать, не его это уровень. Диалоги настройки выводит ПО принтера. Потом все же StartDoc , TextOut и т.д., потом EndDoc, вызываемые браузером. А браузер — не часть web-приложения. Так что печатает не web-приложение, а его исполняющая среда.
Ну и что. Точно так же настройки печати и всё остальное в нативном приложении делает не нативное приложение, а платформенный код. Вообще печатает светодиод, управляемый кодом на платформе, которую ни ты ни я в жизни не видели. Это как-то делает нативные приложения неполноценными?

PD>Тут просто твое непонимание того, что мы обсуждаем. Я изначально просто две вещи сказал : что web-приложения примитивны пока что, и что они опираются на нативный код, то есть в действительности большая часть их возможностей обеспечивается отнюдь не web-кодом.
Да, действительно, я совершенно не понимаю, что мы тут обсуждаем.
Дело в том, что вообще все возможности веб-приложений обеспечиваются отнюдь не веб-кодом. Вот я написал простейшее приложение: <html><body>Hello world!</body></html>. Всё, что оно делает — выводит текст. И вот этот вывод текста (о, ужас!) выполняется самым что ни на есть нативным кодом. Потому что никакого доступа к дисплею у веб-приложения нет.
А код работает крайне сложный — он строит DOM модель документа, подгружает default style sheet, парсит правила в этом style sheet, и вводит в действие движок такой запутанности, что у освоивших его реализацию шерсть на яйцах приобретает характерный серебристый оттенок. Это ещё до того, как собственно вступит в действие платформенная часть — та, где начинается рендер текста со всеми модными ClearType и прочим всяким.

А веб код — он что? Даже JavaScript — это так, буковки. Он сам вообще ничего сделать не может — его интерпретирует интерпретатор. В отличие от Java и C#, в JS не так уж много кода, который можно реально скомпилировать — из-за слабой типизации.

PD>Требования такого вовсе нет, естественно, просто есть констатация факта — в собственно web-коде делается на клиенте очень немного, большая часть — в нативных приложениях/модулях.
Как мы уже выяснили, в "веб-коде" не делается вообще ничего. Всё делается исключительно в нативных приложениях и модулях, одним из которых является JS-engine.
Поэтому ценность такого наблюдения близка к нулю.

PD>Опять ты демонстрируешь непонимание. Не то, что не пишут, а не могут писать. Драйвер в нулевом кольце исполняется, а разработчикам приложений под Windows (NT линии) туда хода нет.
Начиная с Win2k драйвер принтера может работать в третьем кольце. Начиная с Vista — только в третьем. Это так, про "хода нет".
Не говоря уже о том, что нет никаких проблем поставлять и кернелмодный драйвер вместе с приложением. Было бы желание. Поэтому только отсутствие желания останавливает разработчиков.

PD>Лучше ссылку дай, тогда и последую. Для меня Gmail — это только почта, остальное проходит как google.com. У меня на виртуалке как раз никакого pdf-вьюера нет. Давай ссылку, попробую и пойду в реальный мир в малоизвестные приложения.
Ну, собственно рендер выполняется через Google Docs.
Вот я закачал документ: https://docs.google.com/file/d/0B8E17Ogt_3nfSTZBY0lVcVVpVDQ/edit?usp=sharing

Здравствуйте, Sinclair, Вы писали:

S>Вот я написал простейшее приложение: <html><body>Hello world!</body></html>. Всё, что оно делает — выводит текст.

Тут возникает вопрос, что такое "приложение"?
Вот я запустил нотепад и открыл текстовый документ. Текстовый документ в этом случае — это приложение, которое выводит на экран текст — я правильно понимаю ваш ход мысли?

Здравствуйте, Yoriсk, Вы писали:
Y>Вот я запустил нотепад и открыл текстовый документ. Текстовый документ в этом случае — это приложение, которое выводит на экран текст — я правильно понимаю ваш ход мысли?
Не совсем.
Вот у меня есть приложение, вполне себе нативное. Оно ставит вместе с собой файлик EULA.txt. И ссылка на него (шорткат) прописывается инсталлером в Start меню рядом с приложением.
Когда я кликаю на эту ссылку, документ открывается в дефолтном приложении (которым совершенно случайно является Notepad, если у пользователя не стоит какого-нибудь более модного UltraEdit или ещё чего).

С точки зрения приложения, мы реализуем сценарий — "показать пользователю соглашение". А для реализации сценария выбран вот такой вариант, в котором Notepad — это всего лишь низкоуровневый инструмент по выводу текста на экран.

Ход мысли понятен?

Понятно, что ровно те же EULA.txt и Notepad.exe играют совершенно другие роли, когда я (разработчик) подготавливаю файл во время разработки приложения?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Yoriсk, Вы писали:
Y>>Вот я запустил нотепад и открыл текстовый документ. Текстовый документ в этом случае — это приложение, которое выводит на экран текст — я правильно понимаю ваш ход мысли?
S>Ход мысли понятен?

Нет, не понятен. Давайте попроще пока, без сторонних приложений, eula, сценариев и т.д.

Какая разница между показом вашеим приложением(страница "Hello world" в броузере) и моим (текст "Hello world" в ноутпаде)? Можно ли Hello_world.txt считать приложением наравне с Hello_world.htm и если нет — то почему?

Здравствуйте, Yoriсk, Вы писали:

Y>Какая разница между показом вашеим приложением(страница "Hello world" в броузере) и моим (текст "Hello world" в ноутпаде)? Можно ли Hello_world.txt считать приложением наравне с Hello_world.htm и если нет — то почему?
В общем случае — можно.

Здравствуйте, Sinclair, Вы писали:

Ладно, давай заканчивать. Результат наших дискуссий — как всегда

За тобой последнее слово. Я продолжать не буду.

S>Ну и что. Точно так же настройки печати и всё остальное в нативном приложении делает не нативное приложение, а платформенный код. Вообще печатает светодиод, управляемый кодом на платформе, которую ни ты ни я в жизни не видели. Это как-то делает нативные приложения неполноценными?

S>Дело в том, что вообще все возможности веб-приложений обеспечиваются отнюдь не веб-кодом. Вот я написал простейшее приложение: <html><body>Hello world!</body></html>. Всё, что оно делает — выводит текст. И вот этот вывод текста (о, ужас!) выполняется самым что ни на есть нативным кодом. Потому что никакого доступа к дисплею у веб-приложения нет.
S>А код работает крайне сложный — он строит DOM модель документа, подгружает default style sheet, парсит правила в этом style sheet, и вводит в действие движок такой запутанности, что у освоивших его реализацию шерсть на яйцах приобретает характерный серебристый оттенок. Это ещё до того, как собственно вступит в действие платформенная часть — та, где начинается рендер текста со всеми модными ClearType и прочим всяким.

S>А веб код — он что? Даже JavaScript — это так, буковки. Он сам вообще ничего сделать не может — его интерпретирует интерпретатор. В отличие от Java и C#, в JS не так уж много кода, который можно реально скомпилировать — из-за слабой типизации.

S>Как мы уже выяснили, в "веб-коде" не делается вообще ничего. Всё делается исключительно в нативных приложениях и модулях, одним из которых является JS-engine.


В чем-то ты, конечно, прав. В сущности вопрос можно и иначе поставить. Что входит в состав десктопного приложения ? EXE — безусловно. DLL той же фирмы — безусловно. DLL 3-ей фирмы, поставляемые вместе с EXE или shared ? По-видимому, да. А kernel32.dll ? Она часть Windows, но ее работа в приложении по существу ничем не отличается от работы какой-то собственной DLL. Если и она входит, то почему на ntdll.dll ? А если ntdll.dll, то почему не ntoskrnl.exe ? Так можно и всю Windows в приложение записать.

Ну а если пойти по этому пути, то надо отказаться от твоей точки зрения, что броузер есть исполняющая система и признать его частью web-приложения. Потом его плугины, потом прочие программы и так до ntoskrnl.exe. В итоге действительно теряется предмет дискуссии.

А тем не менее, говоря о десктопных приложениях, никому в голову не придет причислить к ним ядро ОС вместе с драйверами (за исключением разве что его собственных драйверов, если они есть), и даже kernel32.dll. Может, не слишком точно, и уж во всяком случае не формально, но мы всегда отдаем себе отчет, что именно относится к данному приложению, а что — к его поддержке в ОС или иными средствами.

Вот и в web-приложении есть код, выполняющийся на сервере (мы о нем не говорили, но тут сомнений нет), и код JS и т.п, выполняющийся на клиенте. Вот этот JS и т.п. и лежит по одну сторону, а броузер и все, что ниже или параллельно ему — по другую. И в этом смысле броузер и остальные есть среда, а не сама программа.

И основную работу тут именно среда делает. Те же картинки рендерит. В отличие от десктопной программы, которая их сама рендерит (конечно, не без помощи gdi32.dll и т.д.)



PD>>Лучше ссылку дай, тогда и последую. Для меня Gmail — это только почта, остальное проходит как google.com. У меня на виртуалке как раз никакого pdf-вьюера нет. Давай ссылку, попробую и пойду в реальный мир в малоизвестные приложения.
S>Ну, собственно рендер выполняется через Google Docs.
S>Вот я закачал документ: https://docs.google.com/file/d/0B8E17Ogt_3nfSTZBY0lVcVVpVDQ/edit?usp=sharing

Согласен. Не знал.

Здравствуйте, Pavel Dvorkin, Вы писали:


PD>В чем-то ты, конечно, прав. В сущности вопрос можно и иначе поставить. Что входит в состав десктопного приложения ? EXE — безусловно. DLL той же фирмы — безусловно. DLL 3-ей фирмы, поставляемые вместе с EXE или shared ? По-видимому, да. А kernel32.dll ? Она часть Windows, но ее работа в приложении по существу ничем не отличается от работы какой-то собственной DLL. Если и она входит, то почему на ntdll.dll ? А если ntdll.dll, то почему не ntoskrnl.exe ? Так можно и всю Windows в приложение записать.

Вопросы ты ставишь совершенно верные. Однако делаешь совершенно неожиданные выводы.

PD>Ну а если пойти по этому пути, то надо отказаться от твоей точки зрения, что броузер есть исполняющая система и признать его частью web-приложения. Потом его плугины, потом прочие программы и так до ntoskrnl.exe. В итоге действительно теряется предмет дискуссии.
Именно.

PD>А тем не менее, говоря о десктопных приложениях, никому в голову не придет причислить к ним ядро ОС вместе с драйверами (за исключением разве что его собственных драйверов, если они есть), и даже kernel32.dll. Может, не слишком точно, и уж во всяком случае не формально, но мы всегда отдаем себе отчет, что именно относится к данному приложению, а что — к его поддержке в ОС или иными средствами.
Совершенно верно.

PD>Вот и в web-приложении есть код, выполняющийся на сервере (мы о нем не говорили, но тут сомнений нет), и код JS и т.п, выполняющийся на клиенте. Вот этот JS и т.п. и лежит по одну сторону, а броузер и все, что ниже или параллельно ему — по другую. И в этом смысле броузер и остальные есть среда, а не сама программа.
Да, это разделение совершенно корректно.

PD>И основную работу тут именно среда делает. Те же картинки рендерит. В отличие от десктопной программы, которая их сама рендерит (конечно, не без помощи gdi32.dll и т.д.)
А вот тут начинается какая-то чушь. Ситуации для нативного приложения и для веб-приложения совершенно одинаковы. Десктопная программа тоже "сама" практически ничего не делает. Доступа к железу у неё нет. Десктопная программа полагается на исполняющую среду, и большинство нативных программистов имеют весьма смутное представление о том, что "на самом деле" происходит в
этой среде ниже уровня прикладного винапи.
И это как раз хорошо — потому что позволяет разработчикам платформы развивать её более-менее независимо от приложений. И потому, что позволяет разработчикам приложений сосредоточиться на полезностях, а не на борьбе с элементарщиной.

Термином "основная работа" ты сам себя гипнотизируешь. В том смысле, что, например, для банковского приложения основная работа — это перевод денег. А вовсе не рендер картинок. Поэтому совершенно неважно, как именно рендерятся картинки в приложении.
А если захочется доказать себе, что уж нативное-то приложение имеет больше возможностей по рендеру картинок, то придётся почитать про тег canvas, который представляет собой аналог DeviceContext из GDI, и разница вообще сотрётся до неразличимой.


PD>>>Лучше ссылку дай, тогда и последую. Для меня Gmail — это только почта, остальное проходит как google.com. У меня на виртуалке как раз никакого pdf-вьюера нет. Давай ссылку, попробую и пойду в реальный мир в малоизвестные приложения.
S>>Ну, собственно рендер выполняется через Google Docs.
S>>Вот я закачал документ: https://docs.google.com/file/d/0B8E17Ogt_3nfSTZBY0lVcVVpVDQ/edit?usp=sharing
PD>Согласен. Не знал.
Это только пример. Первые варианты у них были чудовищные — скажем, результаты анализов InVitro невозможно было прочитать. Постепенно допилили движок, сейчас всё работает вполне себе приемлемо. Принципиальных причин не сделать ещё и редактор нету.

Здравствуйте, Sinclair, Вы писали:

Обещал не отвечать, но пришло в голову одно замечание.


S>>>Вот я закачал документ: https://docs.google.com/file/d/0B8E17Ogt_3nfSTZBY0lVcVVpVDQ/edit?usp=sharing
PD>>Согласен. Не знал.
S>Это только пример. Первые варианты у них были чудовищные — скажем, результаты анализов InVitro невозможно было прочитать. Постепенно допилили движок, сейчас всё работает вполне себе приемлемо. Принципиальных причин не сделать ещё и редактор нету.

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

Сравним 2 случая

1. pdf рендерится Goggle Docs
2. pdf рендерится с помощью Adobe плугина.

Есть разница ? ИМХО все же есть. В одном случае это делает что-то там (я не знаю что, то ли js, то ли еще что-то) в самой странице, присланной с сервера, а в другом — сторонний нативный код. Я не говорю о том, как рендерится, тут и, верно, можно до ntoskrnl.exe дойти. Я лишь сам факт отмечаю — рендерит либо код внутренний, либо внешний.

Если следовать твоей логике, то и в случае внешнего рендеринга мы имеем web-приложение. Тогда зачем переделывать под внутренний рендеринг ? Это же ничего не добавит в идее (именно в идее, о технической стороне я не говорю).

Но если внешний рендеринг pdf находится в рамках концепции web-приложения, то почему бы не объявить web-приложением некий pdf, находящийся на совершенно статическом сайте без единой строчки кода ? В одном случае сайт делает мне pdf, я его загружаю с помощью Adobe и рендерю. В другой случае сайт присылает мне pdf, я его запускаю с помощью Adobe и рендерю. В чем отличие ? Только в том, что во втором случае pdf не генерируется по моей просьбе с моими данными, а статичен ? Так и в первом случае мне могли бы присылать некий статичный pdf иногда.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Обещал не отвечать, но пришло в голову одно замечание.
Да ладно. Будем считать, что это было необязывающее обещание

PD>Тебе не кажется. что этот пример несколько играет против твоих рассуждений ?
Неа.

PD>1. pdf рендерится Goggle Docs
PD>2. pdf рендерится с помощью Adobe плугина.

PD>Есть разница ? ИМХО все же есть.
Да. Основная разница — требования к клиентской платформе.

PD>В одном случае это делает что-то там (я не знаю что, то ли js, то ли еще что-то) в самой странице, присланной с сервера, а в другом — сторонний нативный код. Я не говорю о том, как рендерится, тут и, верно, можно до ntoskrnl.exe дойти. Я лишь сам факт отмечаю — рендерит либо код внутренний, либо внешний.
Понятия "внутреннего" и "внешнего" кода могут быт разными. С точки зрения пользователя, "внутренний" код — это тот, который приложение "принесло с собой" невидимым для пользователя образом. А "внешний" — это тот код, который приложение рассчитывает обнаружить. Если уточнять дальше, то начинаются неприятные нюансы — например, ActiveX будет "внутренним", если удалось его поставить без унижения пользователя. А если страничка рендерит заглушку типа "для продолжения вам нужно скачать убермегакомпонент с сайта злоумышленники.ком и проигнорировать десяток ворнингов" — то код внешний.
Хотя с точки зрения процедуры исполнения оба кода устроены совершенно одинаково.

Есть и обратная штука — тот же самый Flash играется в IE при помощи ActiveX, и типичное веб-приложение рассчитывает на его наличие. Тем не менее, его penetration ratio близок к 99%, поэтому для большинства пользователей flash-приложение никакого "внешнего" кода не требует.

PD>Если следовать твоей логике, то и в случае внешнего рендеринга мы имеем web-приложение. Тогда зачем переделывать под внутренний рендеринг ? Это же ничего не добавит в идее (именно в идее, о технической стороне я не говорю).
Совершенно правильный вопрос. Большинство профессиональных веб-приложений, которые хотят выводить документы на печать, генерируют PDF. Просто потому, что в чистом HTML (и других кросс-платформенных форматах, напрямую поддерживаемых браузером) управление видом документа на печати слишком ненадёжно, а PDF реализован для чуть менее чем всех платформ.
Гугл решал совсем другую задачу — у него казуальные пользователи, и ему важнее была всеобщая доступность (включая те 2% людей, у кого нет Adobe), а не точное соблюдение полиграфических ожиданий автора документа.

PD>Но если внешний рендеринг pdf находится в рамках концепции web-приложения, то почему бы не объявить web-приложением некий pdf, находящийся на совершенно статическом сайте без единой строчки кода ? В одном случае сайт делает мне pdf, я его загружаю с помощью Adobe и рендерю. В другой случае сайт присылает мне pdf, я его запускаю с помощью Adobe и рендерю. В чем отличие ?
Совершенно верно — нет никаких отличий. На стороне клиента отличить статический PDF от динамического решительно невозможно.
И таких приложений в реальной практике — тысячи. Вот, например, Билайн присылает мне счета в PDF, и даёт их же скачать через их "личный кабинет". Я понятия не имею, хранят ли они эти файлы в какой-то файловой системе, или создают On demand всякий раз, как я их запрашиваю (то есть практически никогда). У меня и способа-то нет никакого отличить эти ситуации друг от друга.

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

В "десктопе" простые случаи выглядят симметрично. Результаты

start helloworld.txt

и

start helloworld.exe

будут удивительно похожи (если я зарегистрирую в качестве дефолтной команды для .txt запуск cmd.exe с командой type %1).
Незнакомый с программированием человек может считать это двумя неразличимыми версиями одной и той же программы, хотя всё в программисте будет бунтовать против такой трактовки.
Различия начнутся в тот момент, когда мы захотим интерактивности. helloworld.exe легко доработать так, чтобы в ответ на

start helloworld.exe Pavel

она выводила

Hello Pavel!

А вот helloworld.txt такому трюку не подвержен.
А в вебе всё гораздо размытее. Можно идти-идти по сайту, и постепенно оказаться по уши в приложении. А можно иметь приложение, 70% контента в котором отдаётся с веб-сайта.

Здравствуйте, Sinclair, Вы писали:


PD>>Обещал не отвечать, но пришло в голову одно замечание.
S>Да ладно. Будем считать, что это было необязывающее обещание

Ну раз так, отвечу еще раз. На один пункт.

PD>>Но если внешний рендеринг pdf находится в рамках концепции web-приложения, то почему бы не объявить web-приложением некий pdf, находящийся на совершенно статическом сайте без единой строчки кода ? В одном случае сайт делает мне pdf, я его загружаю с помощью Adobe и рендерю. В другой случае сайт присылает мне pdf, я его запускаю с помощью Adobe и рендерю. В чем отличие ?
S>Совершенно верно — нет никаких отличий. На стороне клиента отличить статический PDF от динамического решительно невозможно.

То есть статический сайт, со страницей, где есть линк на их же pdf, ты готов признать web-приложением ?

Тогда пойдем дальше. Пусть есть некий сайт, где разрешен browse directory, и в этом directory лежит некое количество файлов. Вот этот, например

http://www.sai.msu.su/apache/hadoop/common/

Это тоже web-приложение ? Конечно, может там на этом сайте еще что-то есть, но допустим, что больше ничего там нет.

А если это web-приложение, то почему не назвать web-приложением ftp-сервер ? Только из-за того, что там другой протокол ? Да, конечно, этого достаточно, чтобы сказать, что ftp-сервер не принадлежит к http/www. Но делает-то он совершенно то же.

Что-то тут не то...

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>То есть статический сайт, со страницей, где есть линк на их же pdf, ты готов признать web-приложением ?

PD>Тогда пойдем дальше. Пусть есть некий сайт, где разрешен browse directory, и в этом directory лежит некое количество файлов. Вот этот, например
PD>http://www.sai.msu.su/apache/hadoop/common/
PD>Это тоже web-приложение ? Конечно, может там на этом сайте еще что-то есть, но допустим, что больше ничего там нет.

PD>А если это web-приложение, то почему не назвать web-приложением ftp-сервер ? Только из-за того, что там другой протокол ? Да, конечно, этого достаточно, чтобы сказать, что ftp-сервер не принадлежит к http/www. Но делает-то он совершенно то же.

PD>Что-то тут не то...
Веб приложение от веб сайта отличается не технически, а функционально. Сайт — это коллекция документов, обычно квазистатических. Приложение подразумевает некоторую интерактивность.
Поэтому говорят, например, "сайт на sharepoint", хотя с обратной стороны вообще никаких файлов нет (в терминах вроде "browse directory", которые ты используешь).
Или наоборот — например, phpBB, не к ночи будь помянут, на заре своей карьеры работал на основе набора статических файлов (которые он тупо перегенерировал всякий раз, как добавлялся новый пост в форум).

Протокол ftp в веб-приложениях тоже используется, хотя и очень редко. Например, в сервисах батч-процессинга бухгалтерских данных схема "загрузил на ftp, получил письмо со ссылкой на результат — скачал" встречается до сих пор. В основном по историческим причинам — ftp это единственный из популярных протоколов, в который встроена "докачка вверх". А в HTTP из коробки её нету, поэтому загрузка в сервер большого файла может основательно испортить настроение. Не то, чтобы эту докачку невозможно было реализовать, просто это а) требует усилий и б) не будет поддерживаться существующими клиентами. Сейчас каналы гораздо лучше, чем 10 лет назад, поэтому, к примеру, можно заливать фотки для печати по 5 мегабайт размером. А в 2000 году шансы на то, что пятимегабайтный файл влезет в сервер с первой попытки, были призрачными. Потому и ftp, с восстановлением после сбоя.

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

Здравствуйте, IT, Вы писали:

IT>А это скриптовый язык, т.е. язык, предназначение которого — лёгкие подпорки и мелкие затычки.

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

IT>Возьмите ради разнообразия какой-нибудь самый обычный энтерпрайз проект на годик и на самых обычных человек на 10 индусов и перепишите его на JS.

Без проблем — сразу уйдет вся суета с маппингом из базы в ОРМ, потом в ДТО, потом в СОАП.

Энтузиаст жабаскрипта

Здравствуйте, Sinclair, Вы писали:


PD>>То есть статический сайт, со страницей, где есть линк на их же pdf, ты готов признать web-приложением ?

PD>>Что-то тут не то...
S>Веб приложение от веб сайта отличается не технически, а функционально. Сайт — это коллекция документов, обычно квазистатических. Приложение подразумевает некоторую интерактивность.

Хм...

Рассмотрим три гипотетических сайта

1. Шлет мне форму с TextBox и Submit, по нажатию Submit, возвращает мне pdf с содержимым этого TextBox
2. Шлет мне форму с Submit по нажатию Submit, возвращает мне pdf с чем-то своим, статический pdf
3. Шлет мне страницу, в которой линк на pdf из пункта 2.

Первый по твоему определению — web-приложение. Второй тоже (есть же интерактивность!). А третий, выходит, нет. А в чем разница между вторым и третьим с точки зрения пользователя ? В нажатии кнопки, а не линка ? Так линк можно и в виде кнопки сделать...


S>Протокол ftp в веб-приложениях тоже используется

<skipped>


Не понял ты меня, не для того я его привел, и зачем-то прочитал лекцию по ftp

Здравствуйте, Аноним, Вы писали:

А>Какие на ваш взгляд есть недостатки ?

А>Пока вижу 2

А>1) javascript — открытый код, то есть где он не будет удовлетворять требованиям безопасности придется отказываться от ajax в данных формах, в результате замедление отклика интерфейса.
А>2) hotkeys — веб приложение не может полноценно обрабатывать hotkey часть из них забирает броузер.

Веб приложения — это не только интернет. Сейчас много интранет приложений переносятся в броузер и такие приложения писать и поддерживать куда как проще чем ГУИ приложение с серверной частью.

Здравствуйте, avpavlov, Вы писали:

A>Веб приложения — это не только интернет. Сейчас много интранет приложений переносятся в броузер и такие приложения писать и поддерживать куда как проще чем ГУИ приложение с серверной частью.

Писать и поддерживать их как раз сложнее. Выигрыш там только в развёртывании на клиенте.

Здравствуйте, Yoriсk, Вы писали:

Y>Здравствуйте, avpavlov, Вы писали:

A>>Веб приложения — это не только интернет. Сейчас много интранет приложений переносятся в броузер и такие приложения писать и поддерживать куда как проще чем ГУИ приложение с серверной частью.

Y>Писать и поддерживать их как раз сложнее.

У меня обратное мнение (опыт имею и с тем и с тем, если что)