Спасибо, познавательная статья. Не подскажите, как можно грамотно зациклить выполнение задачи, т.е. реализовать что-то наподобие таймера, только без интервала ожидания?
Статья больше похожа на эмоциональный порыв, возникший после регистрации Вас в SK. Пока же не видно никаких плюсов участия в нем, кроме как немного «попиариться». Сейчаc SK — больше похоже на очередной слив денег в строительство. Про такие стройки в виде наукоградов и технопарков все и так наслышаны за последний десяток лет, а воз и ныне там, только вот стройки становятся все масштабнее и стоят все дороже.
Я тоже было начитался хвалебных статей, посмотрел видео-роликов, зарегистрировался на IT-городе как физ.лицо, начал заполнять анкету проекта и… встал в ступор в разделе участия в проекте нерезидента. До сих пор не могу понять зачем вводить такое условие. Нет у меня близких друзей за бугром. Да и зачем в моих (российских) инновациях обязательно должен участвовать человек из-за границы?
С полит.точки зрения, если кто-то захочет, то может увидеть в этом еще одну попытку утечки мозгов, идей, разработок. Я этого не вижу, но и понять не могу.
>> Делаем сами remote-desktop клиент для смартфона
>> Но есть же TeamViewer, с клиентской частью для Андроида и iOS
Хотелось бы сразу видеть «заточку» под абстрактного клиента.
>> Могу организовать цикл статей если будет интересно, материал готовый есть.
Очень даже не помешает!
Интерес велик. Очень радует текстовый язык запросов и обещание возможности встраивать ее в свои приложения в виде dll для использования, например, на хостинге.
Сравнение со всеми не нужно, но хотелось бы сравнения с db4o.
Я тут еще раз глянул в Вики по вопросу, что же такое REST. И еще больше убедился в том, что критика в мой адрес по вопросу, почему представленная реализация не подпадает под шаблон REST, не правомерна.
Если имеется ввиду автогенерация клиентских прокси, то как правило в общедоступной среде такая возможность на сервере отключается, а прикладным разработчикам предоставляются уже готовые их реализации. Пример: все публичные веб-проекты предоставляют уже готовый клиентский API под конкретную платформу без необходимости для вас исследовать сервис на наличие методов. Мало ли какие методы есть у сервиса, вы ничего о них знать не должны в принципе. С другой стороны, вы как разработчик сервиса прекрасно знаете все о своем детище :)
Прикладную сборку из Bin-а невозможно выкачать, так же как и загрузить, Вы же это знаете. А задосить можно любой сервис, это никак не связано.
Кстати, у меня реализованы виртуальные хосты, т.е. домены внутри домена самого сервера приложений. Есть админское API, через который я могу удаленно инсталлировать, запускать/останавливать и удалять приложения.
Да, именно, хочу многое, чтобы не надо было думать в ходе дальнейшей прикладной разработки, как реализовать то, что уже изначально должно быть. Поэтому — читаем еще раз тему топика, где жирными словами написано "… свой Application Server".
А Вам предлагаю написать о своей практике использования WCF Web API. Еще круче, если будет описание «внутренностей».
«Сложные» я имел ввиду вложенные, т.е. граф объектов.
Поддержка IHttpAsyncHandler — это гуд, потому как родной .svc — только синхронный.
Все хорошо, но разве не утомительно помимо самих методов регистрировать еще мапинги на них и каждый метод аннотировать атрибутом?
А в общем, Web API, которое Вы упомянули — хорошее дополнение к WCF, но только надо сказать, что это коммунити проект, ну типа моего :)
А подключение методов без перекомпиляции сервиса очень удобно. Пример — вы автор уже работающего сервиса, но ему нужна доп.функциональность. Можно отдать реализацию функционала другому разработчику без предоставления исходников сервиса, не все же самому писать. А вызов системных функций и из GAC конечно же блокирован.
Вы не знаете, реализована ли в Web API работа с потоковым видео и дозагрузка файлов?
Вы лукавите, с WCF не все так просто. В Вашем шаблоне еще нет Web.config-а, метод не сможет вернуть Stream, сложные Json структуры для него не «съедобны». Добавить метод — пересобрать сервис.
К тому же WCF «зашит» как синхронный хэндлер, что вызывает подозрение в ограничениях, таких же как обработка .aspx
Ах, если бы WCF был так хорош…
Надо просто попробовать. Сделать WCF сервис и написать для него четыре простых клиента, как в моем примере, с вызовом всего лишь 2-х методов: GetImageInfo() и GetImage(). И посмотреть во что это выльется.
service.ashx — всего лишь фабрика обработчиков, что ненормального в url? REST стиль — это всего-лишь один из способов адресации. Суть же не в этом.
Похоже, я упустил из вида описание самой «фишки» предлагаемого подхода. У сервера приложений всего лишь одна точка входа — "/service.ashx", никаких других хэндлеров нет и они не нужны! Этот базовый адрес с помощью несложного клиентского API, который легко пишется для любого типа клиента, динамически выстраивается в нужный url, а на сервере приложений HttpRequest превращается в вызов через Reflection соответствующего метода из указанной сборки.
В следующей статье постараюсь развить эту тему, чтобы идея была более понятна и «прочувствована» :)
Я тоже было начитался хвалебных статей, посмотрел видео-роликов, зарегистрировался на IT-городе как физ.лицо, начал заполнять анкету проекта и… встал в ступор в разделе участия в проекте нерезидента. До сих пор не могу понять зачем вводить такое условие. Нет у меня близких друзей за бугром. Да и зачем в моих (российских) инновациях обязательно должен участвовать человек из-за границы?
С полит.точки зрения, если кто-то захочет, то может увидеть в этом еще одну попытку утечки мозгов, идей, разработок. Я этого не вижу, но и понять не могу.
lock (this.StorageStream)
{
...
}
Вроде как для этого есть ReaderWriterLockSlim.
>> Но есть же TeamViewer, с клиентской частью для Андроида и iOS
Хотелось бы сразу видеть «заточку» под абстрактного клиента.
Очень даже не помешает!
Интерес велик. Очень радует текстовый язык запросов и обещание возможности встраивать ее в свои приложения в виде dll для использования, например, на хостинге.
Сравнение со всеми не нужно, но хотелось бы сравнения с db4o.
Кстати, у меня реализованы виртуальные хосты, т.е. домены внутри домена самого сервера приложений. Есть админское API, через который я могу удаленно инсталлировать, запускать/останавливать и удалять приложения.
Да, именно, хочу многое, чтобы не надо было думать в ходе дальнейшей прикладной разработки, как реализовать то, что уже изначально должно быть. Поэтому — читаем еще раз тему топика, где жирными словами написано "… свой Application Server".
А Вам предлагаю написать о своей практике использования WCF Web API. Еще круче, если будет описание «внутренностей».
Поддержка IHttpAsyncHandler — это гуд, потому как родной .svc — только синхронный.
Все хорошо, но разве не утомительно помимо самих методов регистрировать еще мапинги на них и каждый метод аннотировать атрибутом?
А в общем, Web API, которое Вы упомянули — хорошее дополнение к WCF, но только надо сказать, что это коммунити проект, ну типа моего :)
А подключение методов без перекомпиляции сервиса очень удобно. Пример — вы автор уже работающего сервиса, но ему нужна доп.функциональность. Можно отдать реализацию функционала другому разработчику без предоставления исходников сервиса, не все же самому писать. А вызов системных функций и из GAC конечно же блокирован.
Вы не знаете, реализована ли в Web API работа с потоковым видео и дозагрузка файлов?
К тому же WCF «зашит» как синхронный хэндлер, что вызывает подозрение в ограничениях, таких же как обработка .aspx
Ах, если бы WCF был так хорош…
service.ashx — всего лишь фабрика обработчиков, что ненормального в url? REST стиль — это всего-лишь один из способов адресации. Суть же не в этом.
В следующей статье постараюсь развить эту тему, чтобы идея была более понятна и «прочувствована» :)