Здравствуйте, jarlaxle, Вы писали:
J>Кстати, там кто-то спрашивал о СЛ и хроме...
Я спрашивал.
J>...работает отлично...
Это хорошо!
J>...просто надо бы иногда хром обновлять :О)
А чего его обновлять, мне его Гуглоапдейт обновляет. Сервелат-сайтов не так уж много, попадаю я на них редко. Вот и оказалось, что моя информация о непроигрывании Сервелата Хромом осталась неактуальной.
kuj>>И, кстати, runtime silverlight, как и runtime flex`а, есть под все основные платформы: win, linux, mac.
J>Под линухом считай СЛ-а нет как такового. В 2009 собираются выпустить 3й СЛ, а под линухом пока первый. Второй мунлайнт собираются выпустить к сентябрю (когда наверняка будет бета или рц 3-го СЛ на виндовсе). Чтобы не быть голословным: http://www.mono-project.com/MoonlightRoadmap J>Иногда полезно проверять крики маркетологов микрософт (да и вообще крики любых маркетологов, в том числе и линуксовых) J>Писать на 1м СЛ-е... нет уж увольте.
Да с первым SL все понятно — это было недоразумение. Второй выглядит вполне прилично. Я думаю ничего особо не потеряешь, если сделаешь версию на SL 2.0. Пол года и Moonlight поспеет как-раз, и все тип-топ.
Никто ведь не заставляет писать на SL 3.0
Вообще выбор конечно определяется задачами и целевой аудиторией (ну или клиентом в ряде случаев).
J>На работе я как раз под СЛ пишу. Впечатление — нормально. Т.е. не "ВАУ!!! УХ ТЫ!! ЙОМАЙО!!!". А просто — "нормально". В общем-то при выборе Флекс/СЛ особо не заморачивались, поскольку мы .NET-разработчики и порог вхождения для СЛ-а для нас куда меньше чем для флекса. Вот если бы был 1й СЛ, тогда бы точно перешли на Флекс, а так...
J>Если смотреть по кроссплатформенности и кроссбраузерности, то Флекс на 10 шагов впереди СЛ-а. Кстати, там кто-то спрашивал о СЛ и хроме — работает отлично, просто надо бы иногда хром обновлять :О)
Ну не на 10 порядков. Особенно, если клиенты все на винде и маке.
Десктоп линухов все-равно порядка 1-2% так что можно не заморачиваться особо в большинстве случаев.
J>В целом, СЛ должен нормально работать со всеми браузерами, которые поддерживают модель плагинов нетскейпа (а это почти все браузеры кроме ИЕ, тот С СЛ как с АктивХ работает).
Ок, спасибо за инфу.
kuj>>1. Отсутствие удобной и мощной среды разработки.
Q>Я мельком видел Flex Builder (на основе Eclipse), показался вполне удобным. Но в детали я не вдавался, так что спорить не буду.
Я не так выразился: среда конечно есть, но выглядит весьма бедно и убого на фоне VS + Blender.
__>>А поточнее? Помню где-то читал, что гугл чат в гмейле получает сообщения от сервера. Не могу найти линк к сожалению . S>Сие решительно невозможно — см. RFC2616 "Hypertext Transfer Protocol"
но оно ведь есть? http://en.wikipedia.org/wiki/Comet_(programming)
In 2006, while not really using the term Comet, some applications exposed those techniques to a wider audience: Meebo’s multi-protocol web-based chat application enables users to connect to AOL, Yahoo, and Microsoft chat platforms through the browser; Google added web-based chat to Gmail;
Здравствуйте, master_of_shadows, Вы писали:
S>>>Сие решительно невозможно — см. RFC2616 "Hypertext Transfer Protocol" SD>>но оно ведь есть? http://en.wikipedia.org/wiki/Comet_(programming)
__>Точно, оно. Спасибо.
__>
__>In 2006, while not really using the term Comet, some applications exposed those techniques to a wider audience: Meebo’s multi-protocol web-based chat application enables users to connect to AOL, Yahoo, and Microsoft chat platforms through the browser; Google added web-based chat to Gmail;
Как я понял и Flex и Silverlight имеют встроенную поддержку разных техник для push back: от long response до tcp socket`ов.
kuj>Только это не меняет однонаправленного характера общения. Ведь клиент не сможет в этом же соединении слать данные серверу. Все, что он сможет — это сидеть и читать response stream, а если захочет че-та сказать серверу, то придется делать еще один http post, что откроет еще одно соединение.
но ведь "response stream" может быть ответом на некоторый "POST /webapp/stream?sid=UID". А клиентское приложение может сделать короткий POST (который без сохранения соединения) в духе "POST /webapp/action?sid=UID&code=123¶m=234". Сервер возьмет этот sid=UID и поймет, что запрос был выполнен в пользу того активного соединения, которое подключалось "к адресу" /webapp/stream с таким же sid.
Но вообще поддержка соединения вроде упоминалась в контексте push от сервера
Здравствуйте, std.denis, Вы писали:
kuj>>Только это не меняет однонаправленного характера общения. Ведь клиент не сможет в этом же соединении слать данные серверу. Все, что он сможет — это сидеть и читать response stream, а если захочет че-та сказать серверу, то придется делать еще один http post, что откроет еще одно соединение. SD>но ведь "response stream" может быть ответом на некоторый "POST /webapp/stream?sid=UID". А клиентское приложение может сделать короткий POST (который без сохранения соединения) в духе "POST /webapp/action?sid=UID&code=123¶m=234". Сервер возьмет этот sid=UID и поймет, что запрос был выполнен в пользу того активного соединения, которое подключалось "к адресу" /webapp/stream с таким же sid.
Логично. Но все-равно похоже на костыль с оверхедом.
Здравствуйте, std.denis, Вы писали:
kuj>>Только это не меняет однонаправленного характера общения. Ведь клиент не сможет в этом же соединении слать данные серверу. Все, что он сможет — это сидеть и читать response stream, а если захочет че-та сказать серверу, то придется делать еще один http post, что откроет еще одно соединение. SD>но ведь "response stream" может быть ответом на некоторый "POST /webapp/stream?sid=UID". А клиентское приложение может сделать короткий POST (который без сохранения соединения) в духе "POST /webapp/action?sid=UID&code=123¶m=234". Сервер возьмет этот sid=UID и поймет, что запрос был выполнен в пользу того активного соединения, которое подключалось "к адресу" /webapp/stream с таким же sid. SD>Но вообще поддержка соединения вроде упоминалась в контексте push от сервера
SD>p.s. просто мимо проходил. ни разу не веб-дев
1)Поддержка открытого соединения жрет много ресурсов сервера (потоки, память, само соединение)
2)Поддержка открытого соединения совершенно не способствует балансировке нагрузки
3)Поддержка открытого соединения жрет ресурсы клиента, так как количество соединений на один сервер очень ограничено.
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, Sinclair, Вы писали:
S>> Все зависит от того, что тебе нужно — шашечки или ехать.
AB>Мне ехать с шашечками и, желательно, впереди того самого поезда и с увеличением отрыва.
Anton Batenev однажды (16 марта 2009 16:39) писал в rsdn.flame.comp:
> _> Ну тогда ты наш новый Билл Гейтс. > Если твое пророчество сбудется, обещаю поделиться
Не боишься?
Здравствуйте, jarlaxle, Вы писали:
L>>Фичей назвать можно с большой натяжкой. J>В нашем вот приложении это было бы супер. Нам сообщения от сервера приходят очень часто. L>>Навскидку проблем с этим на Silverlight не вижу, а вот применение все-таки очень ограниченное.
"Было бы супер" — не вижу проблем. По-простому часа на 4 работы.
J>Да ну, если уж Вы не сталкивались, не стоит ставить крест
Я говорил о том, что проблема по сути копеечная и можно за несколько часов реализовать самостоятельно, а посему упоминать редко требуемую функциональность, как фичу — странно.
Кроме того, вещь еще и довольно специфическая, и есть шанс начать использовать, а потом наткнуться на ограничение, для обхода которого времени придется потратить вдвое больше, чем на реализацию своего механизма.
Короче, нужен реальный сценарий использования, без него сложно говорить о чем-то конкретном. Пока мне кажется, что у такой штуки очень много шансов обрасти костылями.
Здравствуйте, master_of_shadows, Вы писали:
__>А чем оно лучше чем хтмл+джава скрипт? Кроме того, что какое-то непонятное чудо-юдо надо инсталить на комп? И как быть с тилипонами/ПДА?
Для мобильных устройств насколько мне известно SilverLight в принципе сейчас отсутствует, а Flash имеется только в варианте Flash Lite, который по сути Flash 7 (в последней версии), т.е. кроме как посмотреть видео и анимацию, ни на что не спобосбен. В настоящее время в рамках Open Screen Project Adobe и поставщики всякого железа занимаются тем, что портируют Flash Player 10 на свои устройства. Кроме того (многих это может не касается, но для меня актуально), FP9, а это уже полноценная платформа для Flex приложений, имеется на консольках, типа PSP, PS3 и т.д.
Здравствуйте, Laurel, Вы писали:
L>>>Фичей назвать можно с большой натяжкой. J>>В нашем вот приложении это было бы супер. Нам сообщения от сервера приходят очень часто. L>>>Навскидку проблем с этим на Silverlight не вижу, а вот применение все-таки очень ограниченное.
L>"Было бы супер" — не вижу проблем. По-простому часа на 4 работы.
J>>Да ну, если уж Вы не сталкивались, не стоит ставить крест
L>Я говорил о том, что проблема по сути копеечная и можно за несколько часов реализовать самостоятельно, а посему упоминать редко требуемую функциональность, как фичу — странно.
L>Кроме того, вещь еще и довольно специфическая, и есть шанс начать использовать, а потом наткнуться на ограничение, для обхода которого времени придется потратить вдвое больше, чем на реализацию своего механизма.
Фишка как раз в том, что во флексе и сильверлайте (про последний не уверен) предусмотрена автоматическая подстройка. Типа если в этом режиме не заработало, пробуем следующий и т.д.
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Здравствуйте, yuriylsh, Вы писали:
kuj>>Попробую просуммировать то, что узнал за последние несколько дней, изучая эту тему.
Y>Возможно, в скором времени можно будет проапдейтить этот список: здесь
.
