оказывается, silverlgiht wcf не знает типа Stream. как workaround, MS рекомендует юзать byte[] social.msdn.microsoft.com
В своей практике я не раз наблюдал ситуации, где при создании насыщенных интернет-приложений (RIA) весь процесс отталкивался от клиентского приложения и от клиентских разработчиков. Часто это касалось Flash-разработки (потому что не секрет, что исторически большинство разработчиков пришло туда "с улицы" с жаждой воплотить свои мегаидеи с помощью упрощенной среды и языка, не требующего строгости, а позволяющего кидать код как попало без каких-либо санкций).
Часто в таких проектах были команды энтузиастов, где и менеджеры, и серверщики были подвержены таким вот общим идеям, а сервер мог писать на каком-нибудь PHP вчерашний флешер. Если проект становился интересен, то набирали профессионалов, приходили уже знающие серверщики. Но я немного не о том.
В описанной выше категории проектов часто возникало недомыслие насчет безопасности. Раз клиент насыщенный, позволяет многое, то многое можно на нем и выполнять. То есть ограничивать пользователя в клиентском приложении. Чтобы он не смог прочитать чужие приватные данные, грохнуть содержимое некоторых таблиц, потратить чужие деньги итд. При этом не принималась во внимание банальная вещь, что не только можно снифферить протокол обмена, а потом подменить клиент. Положим, для его обфускации что-то придумали. Более-менее надежное.
Но подлинная незадача возникает тогда, когда на клиент попросту допущен досадный баг. На сервере досадный баг тоже вполне можно допустить. Но при обнаружении досадного бага на сервере, он фиксится один раз для всех возможных клиентов. Если же вся логика идет на клиенте, то никто не мешает достать годный клиент из кэша браузера и развернуться в полный рост.
Типа того.
Часто в таких проектах были команды энтузиастов, где и менеджеры, и серверщики были подвержены таким вот общим идеям, а сервер мог писать на каком-нибудь PHP вчерашний флешер. Если проект становился интересен, то набирали профессионалов, приходили уже знающие серверщики. Но я немного не о том.
В описанной выше категории проектов часто возникало недомыслие насчет безопасности. Раз клиент насыщенный, позволяет многое, то многое можно на нем и выполнять. То есть ограничивать пользователя в клиентском приложении. Чтобы он не смог прочитать чужие приватные данные, грохнуть содержимое некоторых таблиц, потратить чужие деньги итд. При этом не принималась во внимание банальная вещь, что не только можно снифферить протокол обмена, а потом подменить клиент. Положим, для его обфускации что-то придумали. Более-менее надежное.
Но подлинная незадача возникает тогда, когда на клиент попросту допущен досадный баг. На сервере досадный баг тоже вполне можно допустить. Но при обнаружении досадного бага на сервере, он фиксится один раз для всех возможных клиентов. Если же вся логика идет на клиенте, то никто не мешает достать годный клиент из кэша браузера и развернуться в полный рост.
Типа того.
Пока мы решали, нужны RIA или нет, под боком выросло новое явление — ARIA. Его полное название WAI-ARIA (Web Accessibility Initiative — Accessible Rich Internet Applications). Уже есть статьи на русском — webew.ru .
Тут у нас новый англоязычный блог образовался kachurovskiy.com Читайте, подписывайтесь :)
Сейчас опять выскажу мнение, за которое на меня могут накинуться, но мне оно кажется не лишенным оснований. А мнение состоит в том, что если проектировать пользовательский интерфейс для RIA, то проектировщик должен быть пользователем Маков, а не винды или Линукса. Понятно, что правило не универсальное. Если человек, проектирующий GUI, при этом не завязан на реалии своей системы, а имеет опыт и талант чтобы сделать что-то удобное в необходимой предметной области, то все нормально. Но если, как это иногда бывает, человек пытается скопировать метафоры той оси, на которой работает, то лучше пусть он копирует метафоры Макоси. Такое вот ИМХО.
Не помню, писал ли я тут такой простейший паттерн для RIA, который касается формы регистрации и авторизации. Сформулирую его так: никогда не делайте форму регистрации/авторизации на Flash. Только HTML. Обоснование? Их есть у меня. Смысл в том, что огромное количество пользователей полагаются на браузерные механизмы хранения и ввода логинов/паролей. Плюс существуют менеджеры паролей, работающие с HTML. Если вы делаете форму регистрации/авторизации на Flash, то будьте готовы к тому, что статистика забывания паролей на вашем сервисе будет существенно выше, а пользователи, которые используют механизмы запоминания/ввода паролей будут пользоваться вашими сервисами реже. Например, это касается сервиса FlaPhone. Ну вот могли бы сделать в HTML.
Когда-то я считал, что идеальные RIA ничем не отличаются от десктопных приложений. Теперь я изменил свое мнение. Они должны быть лучше. Много лучше. И делать приложение "под десктоп" нельзя. Например, я глубоко убежден, что метафора файловой системы, пусть и виртуальной, непригодна. Я совершенно не претендую на истину, это мое видение. Но оперировать стоит не файлами, а сущностями, которые эти файлы как бы представляют. Ну и, к слову, в принципе и десктопные системы все больше к этому идут. Скажем, тот же iTunes, который оперирует не файлами, а треками, альбомами итд. Понятно, что за ними стоят файлы, но если я пользую iTunes, то мне пофиг. Я слушаю музыку. А не файлы. Типа того.
Все-таки по части всякого RIA у M$ маркетинг значительно лучше, чем у Адобов. Ну вот есть в их сервелате Deep Zoom, Smooth Streaming, а теперь и Pivot. Два из них просто компоненты. Но носятся с ними как с писаной торбой, вставляют в любую презентацию. Хочешь-нехочешь, а втайне подумаешь, что это что-то великое, и нужно использовать в повседневных проектах. А Smooth Streaming и вовсе обычная шняга, но блин от частоты произнесения слова "халва" во рту и реально слаще :) Это уже не говоря про то, что на каждой презентации M$ твердят про "облачные вычисления". Умеют долбить и додалбливать :)
Готов подписать под каждым словом про Microsoft (с инструментов этой небольшой компании из Редмонта началось мое путешествие в чудесный мир компьютеров). Компания, которая выпускает продукты в стиле «И у нас тоже!» догоняет и возможно перегоняет гигантов отрасли. Так было с Java, так происходит и Flex в частности. Они предлагают полный стек. И предлагают его ооооочень быстро! clck.ru
Знамениты новостной ресурс Infoq.com подготовил подборочку материалов по RIA — infoq.com
Вроде как результаты Best of RIA 2009 insideria.com [insideria.com]
Вобщем по мнению некоторых авторитетных личностей, Adobe Flex сегодня наиболее проработанный продукт для RIA
Расскажите люди, пишущие на Flex и считающие его говном, зачем вы это делаете? Есть же замечательные неговенные AJAX, GWT, сервелат? Зачем жопу мучать? :)