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

S>Здравствуйте, gandjustas, Вы писали:
S> Все таки есть разница при разработке тонкого клиента и терминалов. В терминалах намного проще программирование да во многих случаях выше призводительность.
Счегобы?

S>Для тонкого клиента все равно приходится часть кода переносить на клиента, что не всегда хорошо если машинки слабенькие, следить за состоянием итд.
Следить за состоянием как раз надо в десктопном приложении, ибо там оно неявно.

S>Для терминальных сессий подойдут самые убитые бездискове станции.
А для веба подойдут и мобильные устройства. Их кстати больше чем "бездисковых станций".

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

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

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

S>>Здравствуйте, gandjustas, Вы писали:
S>> Все таки есть разница при разработке тонкого клиента и терминалов. В терминалах намного проще программирование да во многих случаях выше призводительность.
G>Счегобы?
Не все можно выполнить на сервере, а из-за этого приходится таскать данные.
S>>Для тонкого клиента все равно приходится часть кода переносить на клиента, что не всегда хорошо если машинки слабенькие, следить за состоянием итд.
G>Следить за состоянием как раз надо в десктопном приложении, ибо там оно неявно.
За состоянием там не надо следить, так как оно уже выполняется в необходимом контексте, а вот для клиент серверных нужно передавать, сохранять извлекать нужное состояние, что не только нетолько усложняет программирование, но и тормозит выполнение.
S>>Для терминальных сессий подойдут самые убитые бездискове станции.
G>А для веба подойдут и мобильные устройства. Их кстати больше чем "бездисковых станций".
Но и для терминалов тоже. Да и на складе проще работать с терминалами, подключенным оборудованием итд. В том числе и офисе.

S>>Так, что у каждой технологии есть свои плюсы и минусы.
G>Угу, у веба скорее плюсы, а у десктопа скорее минусы для этих самых бизнес-приложений, которые терминальным доступом пытаются закрыть.
Ну плюсы на самом деле в денежках требуемых на программирвание этих систем, а значит является нашим хлебушком.
Я как програмиист 1С смотрю как люди мучаются с переходом 8.2. Я в своем коде стараюсь выводить большую часть выполнения кода на сервер, но много намного проще решается на клиенте. При этом в терминалах народ аж с прошлого века работает на семерках.

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

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

evo>>Здравствуйте, vmpire, Вы писали:
V>>>Что мешает "учить" и то и другое?
evo>>Такой подход мне кажется не эффективным, особенно для новичка. Это не тот случай, где технологии дополняют друг друга или идут параллельно, тут используешь или одно или другое.
evo>>Я понимаю, когда хотя б год поработал с формами, без вопросов надо учить WPF. Но что делать, когда нормально с формс еще не успел разобраться и когда МС сказали, что развивать формс больше не будут?
V>Всё зависит от цели обучения. Если цель — наработка общей эрудиции, то есть неглубокое изучение, то вполне можно учить и то и другое. Например, реализовать одну и ту же задачу на обоих технологиях, что позволит лекко увидеть сильные и слабые стороны.
V>Если целью является конкретная дальнейшая работа, то нужно смотреть, что для этой работы потребуется с большей вероятностью.

Неипите мозг, есть масса более интересных занятий, чем "учить технологии"

Мой голос хз за что

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

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

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

S>>>Здравствуйте, gandjustas, Вы писали:
S>>> Все таки есть разница при разработке тонкого клиента и терминалов. В терминалах намного проще программирование да во многих случаях выше призводительность.
G>>Счегобы?
S> Не все можно выполнить на сервере, а из-за этого приходится таскать данные.
Как раз наоборот. Все можно и нужно выполнить на сервере, на клиенте только отображение, ввод и валидация. Если правильно готовить ajax, то получится гораздо меньше трафика, чем толстый клиент + субд или удаленный рабочий стол.

S>>>Для тонкого клиента все равно приходится часть кода переносить на клиента, что не всегда хорошо если машинки слабенькие, следить за состоянием итд.
G>>Следить за состоянием как раз надо в десктопном приложении, ибо там оно неявно.
S> За состоянием там не надо следить, так как оно уже выполняется в необходимом контексте, а вот для клиент серверных нужно передавать, сохранять извлекать нужное состояние, что не только нетолько усложняет программирование, но и тормозит выполнение.
Весь прикол в том что состояние меняется независимо от клиента. В многопользовательском окружении тебе придется выполнять те же действия. Только в вебе ты сразу так делаешь, у тебя вариантов других нет, а в толстом клиенте есть возможность сделать нехорошо.
В вебе у тебя четко разграничены состояние клиента (в js и полях формы) и состояние сервера (в бд), а в десктопном приложении ты вполне скокойно можешь байндиться на коллекции объектов из ORM а потом удивляться почему savechanges сохраняет то что ты менял на предыдущем экране.


S>>>Для терминальных сессий подойдут самые убитые бездискове станции.
G>>А для веба подойдут и мобильные устройства. Их кстати больше чем "бездисковых станций".
S> Но и для терминалов тоже. Да и на складе проще работать с терминалами, подключенным оборудованием итд. В том числе и офисе.
Ну если нет разницы то зачем париться? Веб доступен по-умолчанию на любом устройстве без установки доп. софта, в том числе можно браузер запусктаь в режиме киоска.

S>>>Так, что у каждой технологии есть свои плюсы и минусы.
G>>Угу, у веба скорее плюсы, а у десктопа скорее минусы для этих самых бизнес-приложений, которые терминальным доступом пытаются закрыть.
S> Ну плюсы на самом деле в денежках требуемых на программирвание этих систем, а значит является нашим хлебушком.
S>Я как програмиист 1С смотрю как люди мучаются с переходом 8.2. Я в своем коде стараюсь выводить большую часть выполнения кода на сервер, но много намного проще решается на клиенте. При этом в терминалах народ аж с прошлого века работает на семерках.
Так 1с7.7 на терминале не от хорошей жизни, а от сложности многопользовательского развертывания и цены лицензий. Именно пытаются победить недостатки существующей версии терминальным доступом. Я предлагаю не создавать недостатки.

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

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

S>>Здравствуйте, gandjustas, Вы писали:
S>> Все таки есть разница при разработке тонкого клиента и терминалов. В терминалах намного проще программирование да во многих случаях выше призводительность.
G>Счегобы?

S>>Для тонкого клиента все равно приходится часть кода переносить на клиента, что не всегда хорошо если машинки слабенькие, следить за состоянием итд.
G>Следить за состоянием как раз надо в десктопном приложении, ибо там оно неявно.
За состоянием на декстопе не надо, т.к. оно уже выполняется в определенном контексте, а вот для тонкого клиента приходится это самое состояние таскать туда сюда, и не всегда это малый объем данных, что приводит к замедлению.
S>>Для терминальных сессий подойдут самые убитые бездискове станции.
G>А для веба подойдут и мобильные устройства. Их кстати больше чем "бездисковых станций".
Ну на мобильных устройствах не всегда удобно. Все же монитор как то привычнее, плюс подключение разного торгового, складского оборудования.

S>>Так, что у каждой технологии есть свои плюсы и минусы.
G>Угу, у веба скорее плюсы, а у десктопа скорее минусы для этих самых бизнес-приложений, которые терминальным доступом пытаются закрыть.
Ну плюсы прежде всего в хлебушке, т.к. нужно все это дело прграммировать. К 1Совец вижу как народ на 8.2 переходит и мучается, а на 7 ках еще с прошлого века на терминалах сидят и не окают.
А мне лично побарабану на чем деньги зарабатывать, но я вижу (вернее знаю на опыте) плюсы и минусы двух этих технологий.

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

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

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

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

S>>>>Здравствуйте, gandjustas, Вы писали:
S>>>> Все таки есть разница при разработке тонкого клиента и терминалов. В терминалах намного проще программирование да во многих случаях выше призводительность.
G>>>Счегобы?
S>> Не все можно выполнить на сервере, а из-за этого приходится таскать данные.
G>Как раз наоборот. Все можно и нужно выполнить на сервере, на клиенте только отображение, ввод и валидация. Если правильно готовить ajax, то получится гораздо меньше трафика, чем толстый клиент + субд или удаленный рабочий стол.
А афик то там только изменение экранов. Куда уж меньше то?
S>>>>Для тонкого клиента все равно приходится часть кода переносить на клиента, что не всегда хорошо если машинки слабенькие, следить за состоянием итд.
G>>>Следить за состоянием как раз надо в десктопном приложении, ибо там оно неявно.
S>> За состоянием там не надо следить, так как оно уже выполняется в необходимом контексте, а вот для клиент серверных нужно передавать, сохранять извлекать нужное состояние, что не только нетолько усложняет программирование, но и тормозит выполнение.
G>Весь прикол в том что состояние меняется независимо от клиента. В многопользовательском окружении тебе придется выполнять те же действия. Только в вебе ты сразу так делаешь, у тебя вариантов других нет, а в толстом клиенте есть возможность сделать нехорошо.
G>В вебе у тебя четко разграничены состояние клиента (в js и полях формы) и состояние сервера (в бд), а в десктопном приложении ты вполне скокойно можешь байндиться на коллекции объектов из ORM а потом удивляться почему savechanges сохраняет то что ты менял на предыдущем экране.
Ну тут множество подходов. Но если данные хранятся в БД то нефиг их вытакскивать на клиента, другое дело если делать быстрый доступ через локальные базы, за счет кэширования данных, либо стараться вычислять на сервере и передавать на клиента по быстрому каналу. Все жду недождусь, ког да же весь клиентский код можно делать в СУБД. Но ведь состояние это не только БД, но и текущий незаписанный набор данных, ограничения, данные пользователя итд.
S>>>>Для терминальных сессий подойдут самые убитые бездискове станции.
G>>>А для веба подойдут и мобильные устройства. Их кстати больше чем "бездисковых станций".
S>> Но и для терминалов тоже. Да и на складе проще работать с терминалами, подключенным оборудованием итд. В том числе и офисе.
G>Ну если нет разницы то зачем париться? Веб доступен по-умолчанию на любом устройстве без установки доп. софта, в том числе можно браузер запусктаь в режиме киоска.
Только приложение тонадо написать.
S>>>>Так, что у каждой технологии есть свои плюсы и минусы.
G>>>Угу, у веба скорее плюсы, а у десктопа скорее минусы для этих самых бизнес-приложений, которые терминальным доступом пытаются закрыть.
S>> Ну плюсы на самом деле в денежках требуемых на программирвание этих систем, а значит является нашим хлебушком.
S>>Я как програмиист 1С смотрю как люди мучаются с переходом 8.2. Я в своем коде стараюсь выводить большую часть выполнения кода на сервер, но много намного проще решается на клиенте. При этом в терминалах народ аж с прошлого века работает на семерках.
G>Так 1с7.7 на терминале не от хорошей жизни, а от сложности многопользовательского развертывания и цены лицензий. Именно пытаются победить недостатки существующей версии терминальным доступом. Я предлагаю не создавать недостатки.
Нет там как раз из-за скорости, так как для dbf файлы кэшируются и скорость выполнения увеличиваются на порядки, при этом как я писал выше используются премущества локальных баз для хранения состояний, а для SQL это проще в администрировании, надежности и опять же скорости, т.к. вкладываться нужно в серверы а не в клиентские машинки.

кста , почему все решили что аппаратаное ускорение в UI даст приророст?

я могу вам сказать что даже теоретически оно может дать просадку.

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

поэтому в 3д движках используются всякие техники батчинга т.е. упаковки кучи буферов в одит, атласиг(упаковка кучи тестукр в одну) и прочего и строго следится за кол-вом вызовов отрисовки DrawIndexedPrimitive(DIP)
и даже крутость движка опредялется кол-вом DIPов за кадр, чем меньше — тем круче движок.

так вот я ОЧЕНЬ сомневаюсь что ВПФники такие крутые пацаны что смогли на такую сложную структуру впф приложения натянуть технологии упаковки, ибо мне это видится катастофический сложностью, потому что в 3д движках перерисовывается всегда весь экран и есть возможность собрать и подготовить данные.
А в впф нету понятия фпс, поэтому и не понятно как квантовать отрисовку для упаковки, а значит упаковки там нет и кучей мелких отрисовок можно заставить ВПФ приложение лечь.

K>А в впф нету понятия фпс, поэтому и не понятно как квантовать отрисовку для упаковки, а значит упаковки там нет и кучей мелких отрисовок можно заставить ВПФ приложение лечь.

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

и не факт что получится найти золотую середину

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

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

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

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

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

S>>>>>Здравствуйте, gandjustas, Вы писали:
S>>>>> Все таки есть разница при разработке тонкого клиента и терминалов. В терминалах намного проще программирование да во многих случаях выше призводительность.
G>>>>Счегобы?
S>>> Не все можно выполнить на сервере, а из-за этого приходится таскать данные.
G>>Как раз наоборот. Все можно и нужно выполнить на сервере, на клиенте только отображение, ввод и валидация. Если правильно готовить ajax, то получится гораздо меньше трафика, чем толстый клиент + субд или удаленный рабочий стол.
S> А афик то там только изменение экранов. Куда уж меньше то?
Угу проскроллил в одну сторону — полетели байты, проскроллил в другую сторону — аналогично, высокая чувствительность к латентности канала, на каждое нажатие клавиши раундтрип до сервера.
Если правльно готовить ajax, то передаваться будет только изменение данных. Это гораздо меньше.

S>>>>>Для тонкого клиента все равно приходится часть кода переносить на клиента, что не всегда хорошо если машинки слабенькие, следить за состоянием итд.
G>>>>Следить за состоянием как раз надо в десктопном приложении, ибо там оно неявно.
S>>> За состоянием там не надо следить, так как оно уже выполняется в необходимом контексте, а вот для клиент серверных нужно передавать, сохранять извлекать нужное состояние, что не только нетолько усложняет программирование, но и тормозит выполнение.
G>>Весь прикол в том что состояние меняется независимо от клиента. В многопользовательском окружении тебе придется выполнять те же действия. Только в вебе ты сразу так делаешь, у тебя вариантов других нет, а в толстом клиенте есть возможность сделать нехорошо.
G>>В вебе у тебя четко разграничены состояние клиента (в js и полях формы) и состояние сервера (в бд), а в десктопном приложении ты вполне скокойно можешь байндиться на коллекции объектов из ORM а потом удивляться почему savechanges сохраняет то что ты менял на предыдущем экране.
S>Но если данные хранятся в БД то нефиг их вытакскивать на клиента, другое дело если делать быстрый доступ через локальные базы, за счет кэширования данных, либо стараться вычислять на сервере и передавать на клиента по быстрому каналу. Все жду недождусь, ког да же весь клиентский код можно делать в СУБД. Но ведь состояние это не только БД, но и текущий незаписанный набор данных, ограничения, данные пользователя итд.
Ага, то есть ты сам выстраиваешь барьеры, которые уже есть в вебе.
То что ты хочешь сделать "в субд" в вебе делается на сервере, а на клиент попадает ровно то что ты скажешь. И что потом приходит с клиента на сервер ты определяешь. При хороших средствах генерации SQL на сервере пихать кастомный код в БД не имеет большого смысла.

S>>>>>Для терминальных сессий подойдут самые убитые бездискове станции.
G>>>>А для веба подойдут и мобильные устройства. Их кстати больше чем "бездисковых станций".
S>>> Но и для терминалов тоже. Да и на складе проще работать с терминалами, подключенным оборудованием итд. В том числе и офисе.
G>>Ну если нет разницы то зачем париться? Веб доступен по-умолчанию на любом устройстве без установки доп. софта, в том числе можно браузер запусктаь в режиме киоска.
S> Только приложение тонадо написать.
Любое приложение надо написать, из воздуха не появится.

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

S>> А афик то там только изменение экранов. Куда уж меньше то?
G>Угу проскроллил в одну сторону — полетели байты, проскроллил в другую сторону — аналогично, высокая чувствительность к латентности канала, на каждое нажатие клавиши раундтрип до сервера.
G>Если правльно готовить ajax, то передаваться будет только изменение данных. Это гораздо меньше.
Так данные то хранить надо. А то народ скролить тысячами строк.
G>>>В вебе у тебя четко разграничены состояние клиента (в js и полях формы) и состояние сервера (в бд), а в десктопном приложении ты вполне скокойно можешь байндиться на коллекции объектов из ORM а потом удивляться почему savechanges сохраняет то что ты менял на предыдущем экране.
Ну с дуру то можно ...
Все о чем ты говоришь легко делается и на декстопном приложении. Разницы абсолютно никакой. Только при Вэбе приложее на клиенте, а при терминалах на сервере.
Вот и вся разница.
S>>Но если данные хранятся в БД то нефиг их вытакскивать на клиента, другое дело если делать быстрый доступ через локальные базы, за счет кэширования данных, либо стараться вычислять на сервере и передавать на клиента по быстрому каналу. Все жду недождусь, ког да же весь клиентский код можно делать в СУБД. Но ведь состояние это не только БД, но и текущий незаписанный набор данных, ограничения, данные пользователя итд.
G>Ага, то есть ты сам выстраиваешь барьеры, которые уже есть в вебе.
G>То что ты хочешь сделать "в субд" в вебе делается на сервере, а на клиент попадает ровно то что ты скажешь. И что потом приходит с клиента на сервер ты определяешь. При хороших средствах генерации SQL на сервере пихать кастомный код в БД не имеет большого смысла.
А на сервер то о откуда попадает? Ну вопервых SQL ущербен по сравнеию с C#, а на хранимые процедуры на Net накладываются ограничения. Так что так или иначе приходится тянуть код с СУБД, а вот здесь уже совсем не тонкий клиент. Межпроцессное взамодействие тормозит, а если учесть что СУБД как правило отдельно от Сервера приложений, то еще и сеть сказывается. Причем существенно, на коротких запросах.
Вобще в идеале конечно взаимодействие должно быть тонкий клиент -> СУБД, что по сути происходит при использовании локальных многопользовательских СУБД.
S>>>>>>Для терминальных сессий подойдут самые убитые бездискове станции.
G>>>>>А для веба подойдут и мобильные устройства. Их кстати больше чем "бездисковых станций".
S>>>> Но и для терминалов тоже. Да и на складе проще работать с терминалами, подключенным оборудованием итд. В том числе и офисе.
G>>>Ну если нет разницы то зачем париться? Веб доступен по-умолчанию на любом устройстве без установки доп. софта, в том числе можно браузер запусктаь в режиме киоска.
S>> Только приложение тонадо написать.
G>Любое приложение надо написать, из воздуха не появится.
Прости недопонял вопроса. Бездисковые станции с подачкой около 5 мб линукса, могут работать при минимуме ресурсов.

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

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

А>>все что работает через GDI работает медленнее чем через DirectX.

A>Вы не имеете ни малейшего понятия как работает видеокарта.

Нус, расскажи как с твоими познаниями "как работает видеокарта" GDI оказывается в выигрыше перед DirectX.
p.s
Попкорн с пивом купил...с нетерпением жду ответа

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

А>...Предположим, надо разработать отображение табличных данных по типу Excel. Будет ли достаточно winform для подобных приложений? Kак я понял из обсуждения, WPF это очень круто, но очень долго в смысле обучения, а winform это просто, но уже старо, что-ли. Так?

Главное, Silverlight для такого проекта не выбирай, ни один из поставщиков библиотек не предлагает нормальный грид, работающий с динамическими данными (костыли с кодогенерацией не в счет). Зачем вообще из силверлайта убрали ITypedList?

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

K>кста , почему все решили что аппаратаное ускорение в UI даст приророст?

Потому что видюха берёт на себя весь геморой по отображению — ей передаются лишь команды.

K>потому что любой писатель 3д движков....

Да хоть 4Д — они тут причём? Интерфейс — двумерный.

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

M>Потому что видюха берёт на себя весь геморой по отображению — ей передаются лишь команды.

я там дальше написал почему "геммой по отображению" это еще не весь геморрой

M>Да хоть 4Д — они тут причём? Интерфейс — двумерный.

при том что впф рендерится через Direct3D, а писатели 3д движков знают особенности работы Direct3D лучше, чем впфники.


например я поставив впервые висту и включив аэро первое что отметил — огромный лаг всего интерфейса по сравнению с хр
тот же самый лаг ощущается и в любом впф приложении

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

А>Нус, расскажи как с твоими познаниями "как работает видеокарта" GDI оказывается в выигрыше перед DirectX.

Даю намёк для проспавших последние 10 лет в тайге: у видеокарты и процессора память не общая и любое использование GPU требует копирования данных.

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

A>>Мне плевать на браузеры, мне нужно обновить содержимое списка не перегружая всей страницы с помощью клавиатурного сокращения. F5 — стандарт. Невозможность использовать стандарт — ограничение веба.
G>f5 — стандарт для "обновить всю страницу", если ты попытаешься наделит ьэту клавишу другим поведением — пользователя не обрадуются. Все равно что сделать по ctrl-x вырезание одной буквы

F5 это стандарт на "обновить". "Всю страницу" — твои домыслы.

G>Это правда жизни. Описанная выше тенденция поддерживается от наколеночных приложений до крупных продуктов от ведущих производителей. Есдиничные исключения в расчет не берем.

Опять громкие заявления без фактов. Единственный кто перешёл на веб за последнее время 1С 8.2. В итоге платформа стала ещё большим говном, чем была.

A>>Это твои домыслы.
G>Это не домыслы, это факт. Консоль управления IIS далеко не самая сложная и не единственная часть Server manager если что.

Вот именно, что это не единственная часть Server Manager.

G>Там 80-й порт, который открыт чуть более чем везде. В отличие от 3389.

Это смешно.

A>>gandjustas, ты не показываешь преимущества веба, ты показываешь убогость своих представлений о терминале. Прекрати, это уже не забавно. У веба действительно есть преимущества объективные перед терминалом, но умудрился не назвать ни одно из них.
G>Ок, давай предложи сценарий обновления приложения в терминале без отключения пользователей. Покажи способ быстро добавить серваки для балансировки нагрузки. Покажи способ работы с приложением в терминале с android по GPRS каналу.

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

G>Ты пытаешься спорить с фактами, которые есть. Приводшь в качестве аргументов что у тебя что-то работает.

Это у тебя что-то не работает. У меня и терминал работает и веб и я знаю место каждого и не пытаюськ ак ты везде протолкнуть только одну технологию.

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

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

A>>>Мне плевать на браузеры, мне нужно обновить содержимое списка не перегружая всей страницы с помощью клавиатурного сокращения. F5 — стандарт. Невозможность использовать стандарт — ограничение веба.
G>>f5 — стандарт для "обновить всю страницу", если ты попытаешься наделит ьэту клавишу другим поведением — пользователя не обрадуются. Все равно что сделать по ctrl-x вырезание одной буквы

A>F5 это стандарт на "обновить". "Всю страницу" — твои домыслы.
Так работают все браузеры. И что ты думаешь люди буду ожидать нажимая f5 в браузере?

G>>Это правда жизни. Описанная выше тенденция поддерживается от наколеночных приложений до крупных продуктов от ведущих производителей. Есдиничные исключения в расчет не берем.
A>Опять громкие заявления без фактов. Единственный кто перешёл на веб за последнее время 1С 8.2. В итоге платформа стала ещё большим говном, чем была.
Ну если ты знаешь только одно приложение, то ты прав

A>>>Это твои домыслы.
G>>Это не домыслы, это факт. Консоль управления IIS далеко не самая сложная и не единственная часть Server manager если что.
A>Вот именно, что это не единственная часть Server Manager.

G>>Там 80-й порт, который открыт чуть более чем везде. В отличие от 3389.
A>Это смешно.
Ну посмейся, порты от этого не откроются.

A>>>gandjustas, ты не показываешь преимущества веба, ты показываешь убогость своих представлений о терминале. Прекрати, это уже не забавно. У веба действительно есть преимущества объективные перед терминалом, но умудрился не назвать ни одно из них.
G>>Ок, давай предложи сценарий обновления приложения в терминале без отключения пользователей. Покажи способ быстро добавить серваки для балансировки нагрузки. Покажи способ работы с приложением в терминале с android по GPRS каналу.
A>Посети курс сертицикации Windows Server и там тебе ответят на эти и многие другие вопросы. Ты зашорен, не умеешь использовать возможности ОС и соё незнание выставляешь как недостатки технологиии с которой не знаком.
Ответь на вопросы.

G>>Ты пытаешься спорить с фактами, которые есть. Приводшь в качестве аргументов что у тебя что-то работает.
A>Это у тебя что-то не работает. У меня и терминал работает и веб и я знаю место каждого и не пытаюськ ак ты везде протолкнуть только одну технологию.
Угу, у тебя очень хорошо работает терминал если на гигабитном канале отзывчивость зависит от mtu.

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

A>>F5 это стандарт на "обновить". "Всю страницу" — твои домыслы.
G>Так работают все браузеры. И что ты думаешь люди буду ожидать нажимая f5 в браузере?

Люди буду ожидать, что работает в программе, а не в браузере.

G>>>Это правда жизни. Описанная выше тенденция поддерживается от наколеночных приложений до крупных продуктов от ведущих производителей. Есдиничные исключения в расчет не берем.
A>>Опять громкие заявления без фактов. Единственный кто перешёл на веб за последнее время 1С 8.2. В итоге платформа стала ещё большим говном, чем была.
G>Ну если ты знаешь только одно приложение, то ты прав

Ничто не мешает тебе расширить список ERP, просто тебе нечем.

G>>>Ок, давай предложи сценарий обновления приложения в терминале без отключения пользователей. Покажи способ быстро добавить серваки для балансировки нагрузки. Покажи способ работы с приложением в терминале с android по GPRS каналу.
A>>Посети курс сертицикации Windows Server и там тебе ответят на эти и многие другие вопросы. Ты зашорен, не умеешь использовать возможности ОС и соё незнание выставляешь как недостатки технологиии с которой не знаком.
G>Ответь на вопросы.

1) Покажи способ обновить код веб-приложения остановки Горячие патчи вызывают проблемы вне зависимости от технологии.
2) Просто берёшь и добавляешь север в NLB кластер. Создать кластер пятиминутное дело.
3) Работа в терминате с Androi dпо GPRS недоступна и вебу, потому что надо печатать. Мы уже договоролись до этого, так что не надо давать задний.

A>>Это у тебя что-то не работает. У меня и терминал работает и веб и я знаю место каждого и не пытаюськ ак ты везде протолкнуть только одну технологию.
G>Угу, у тебя очень хорошо работает терминал если на гигабитном канале отзывчивость зависит от mtu.

Веб-браузер бы там вообще давно завис, так что не надо ля-ля. Ни один веб браузер не выдержит 4-5 синхронных запросов в секунду без лагов.

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


Картинка слегка устаревшая. В четвертом WPF либа называется не milcore, а wpfgfx_v0400. Если верить Вики, то:

It interfaces directly with DirectX and provides basic support for 2D and 3D surfaces, timer-controlled manipulation of contents of a surface with a view to exposing animation constructs at a higher level, and compositing the individual elements of a WPF application into a final 3D "scene" that represents the UI of the application and renders it to the screen.

Так что получается, любой WPF контент считается трехмерной сценой.