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

A>Хмм... в принципе конечно можно и так, но раз уж взялся неплохо былоб.
Там тогда надо еще и для рейтинга и для сообщений такую же конструкцию городить...
Я подумаю.

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

A>дык какой-же там byte[] когда в janus-е есть специальный SpecialByteConverter (или как его там).
Не знаю чего у вас там в янусе, на на сервере, что в базе, что в коде byte[8]. Это я тебе как краевед говорю. И никакого конвертера не надо, все эти byte[] чудным образом нв клиенте получаются и нормально понимаются.

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

A> (Я у себя все равно ее в строку запихнул, ибо колупаться с этими byte да еще в базу потом писать (опять же во что-то надо конвертать или в blob писать)).
Не надо там ничего конвертировать, обычный varbinary, пишется влет туда/обратно без всяких преобразований.

A> А то код в Janus ИМХО может и к ошибкам приводить (на память)

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

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

A>>дык какой-же там byte[] когда в janus-е есть специальный SpecialByteConverter (или как его там).
M>Не знаю чего у вас там в янусе, на на сервере, что в базе, что в коде byte[8]. Это я тебе как краевед говорю. И никакого конвертера не надо, все эти byte[] чудным образом нв клиенте получаются и нормально понимаются.
Не у меня . Я юниксовый пишу... а код в янусе подглядел, там есть этот конвертер. Используется для того, чтоб в конфиге (и/или в базе) хранить последние версии строчек. К тому же byte[] у меня превращается в sequence<byte> что при разных размерах байта и разных база может быть мега гимморой. Понятное дело у Janus/C# на MS/Intel проблем никаких не будет.

A>> Тогда может действительно лучше строку?
M>Нет, там все нормально должно работать, безовсяких конвертеров, и придумывать на сервере неизвестно зачем преобразователь в строку и обратно смысла не имеет.
Ну тебе виднее. Просто байты разных размеров бывают. По этому возиться с мэпом в 8 окетов, потом их в зависимости от базы пихать туды-сюды. Не, нафиг нафиг . По этому народ (имеется ввиду разработчики януса) особенно не заморачивась на входе/выходе его в/из строку превращают. Вот и думается мне, что если и я вынужден это же самое делать, то может перенести эту логику на сервер. Пусть сам со своими байтами разбирается, клиент будет уже строку получать.


ЗЫ: А вообще конечно смотри сам. Просто хочется чего-то лучшего

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

A>Не у меня . Я юниксовый пишу... а код в янусе подглядел, там есть этот конвертер. Используется для того, чтоб в конфиге (и/или в базе) хранить последние версии строчек. К тому же byte[] у меня превращается в sequence<byte> что при разных размерах байта и разных база может быть мега гимморой. Понятное дело у Janus/C# на MS/Intel проблем никаких не будет.

Тебе с этими данными ничего делать не надо. Что принял с сервера, то ему назад и передал.

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

M>Вообщем новый сервис януса: http://rsdn.ru/ws/JanusAT.asmx, который краше прежнего,
M>работает вместо датасетов с бизнес-объектами, тянет бомбочки с сайта и тянет список форумов отдельно...

Вопрос:
В моей реализации будет поддерживаться несколько пользователей в одной базе. По этому возник вопрос,
насколько данные получаемые по GetNewData зависят от пользователя под которым эти данные вытаскиваются.
Т.е. допустим имеем такую картину:

userA ->
    Forum1
    Forum2

userB ->
    Forum1
    Forum3

Дык вот, могу ли я например из под юзера userA или даже из под дополнительного юзера userC
получить данные для всех форумов одним запросом.

userName = userC
passwd   = xxxxx
subscribedForums
   Forum1
   Forum2
   Forum3

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

A>Дык вот, могу ли я например из под юзера userA или даже из под дополнительного юзера userC
A>получить данные для всех форумов одним запросом.

Можешь. И дополнительным, и любым из них. Разница будет только для пользователей — членов команды. Их смешивать с обычными не стоит.

Здравствуйте, aka50, Вы писали:
A>В моей реализации будет поддерживаться несколько пользователей в одной базе.
Это, кстати, неплохо было бы организовать и в Windows версии

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

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

A>>Дык вот, могу ли я например из под юзера userA или даже из под дополнительного юзера userC
A>>получить данные для всех форумов одним запросом.

A>Можешь. И дополнительным, и любым из них. Разница будет только для пользователей — членов команды. Их смешивать с обычными не стоит.

А чем именно? Хотя ладно. Учту. Сделаю пока для обычных юзверей. Потом расскажите чего там такого для членов команды .

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

A>насколько данные получаемые по GetNewData зависят от пользователя под которым эти данные вытаскиваются.
На сайте есть разграничение прав, и есть часть форумов, которые ряду пользователей недоступны.

A>Дык вот, могу ли я например из под юзера userA или даже из под дополнительного юзера userC
A>получить данные для всех форумов одним запросом.
Теоретически да, достаточно в RequestForumInfo положить нужный список форумов, но это будет работать только в том случае, если все пользователи обладают одинаковыми правами.
При вытягивании сообщений, на полученный список форумов накладывается список форумов доступный пользователю для скачивания, и выбираются только сообщения присутствующие в обоих списках.
В дальнейшем, я надеюсь, система разграничения прав будет только расширяться, так что задачка по организации многопользовательской клиентской базы не самая простая.

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

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

A>>насколько данные получаемые по GetNewData зависят от пользователя под которым эти данные вытаскиваются.
M>На сайте есть разграничение прав, и есть часть форумов, которые ряду пользователей недоступны.
Ок. Понятно.

A>>Дык вот, могу ли я например из под юзера userA или даже из под дополнительного юзера userC
A>>получить данные для всех форумов одним запросом.
M>Теоретически да, достаточно в RequestForumInfo положить нужный список форумов, но это будет работать только в том случае, если все пользователи обладают одинаковыми правами.
M>При вытягивании сообщений, на полученный список форумов накладывается список форумов доступный пользователю для скачивания, и выбираются только сообщения присутствующие в обоих списках.
M>В дальнейшем, я надеюсь, система разграничения прав будет только расширяться, так что задачка по организации многопользовательской клиентской базы не самая простая.

Может тогда дать небольшую помощь со стороны сервера?
Можно предложить такую схему:
1. Вводится тип пользователя MultiUser.
2. Ему дается право только на выполнение следующих методов сервиса (ну и подобных им)

   getNewUsers
   getTopicByMessage
   getNewData
   getForumList

3. Любой другой тип пользователя может поднять права некоторого MultiUser-a до своих реальных прав.

В итоге получаем возможность синхронизации данных при любых правах доступа (MultiUser получит объединение множеств прав доступа его пользователей).
При этом любые PostChange возможны только из под реальных прав пользователя. Для этого MultiUser-клиент сохраняет в памяти пароль для каждого своего реального пользователя и в случае утери, перезагрузки или просто прокисания по таймауту, MultiUser-клиент может попросить своего пользователя ввести пароль заного, при этом клиент реального пользователя может просто передавать его по запросу, если это разрешил пользователь. Это дает возможность не хранить в общей базе пароли обычных пользователей и супер пользователей. И на сервере нет ни одного логина/пароля через которые можно несанкционированно получить доступ к серверу (можно конечно, но только в ReadOnly режиме, что лучше чем если сервер будет ходить из под максимального юзера или нескльких юзеров если их права не являются подмножествами, а только пересекаются).

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

... И на сервере нет ни одного логина/пароля через которые можно несанкционированно получить доступ к серверу (можно конечно, но только в ReadOnly режиме, что лучше чем если сервер будет ходить из под максимального юзера или нескльких юзеров если их права не являются подмножествами, а только пересекаются)....

Имелся ввиду кеширующий сервер который работает под MultiUser аккаунтом.

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

DH>тогда, чтоб и вешать их можно было в оффлайне
Тут все не просто, для корректной работы придется немного переписать логику этих бомбочек на сайте...

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

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

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

M>Вообщем новый сервис януса: http://rsdn.ru/ws/JanusAT.asmx, который краше прежнего,
M>работает вместо датасетов с бизнес-объектами, тянет бомбочки с сайта и тянет список форумов отдельно...
M>Какие еще будут пожелания по небольшой доработке, пока руки дошли?

Веб-сервис (?? а может и не он)

Автор: _FRED_
Дата: 24.07.05

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

_FR>Веб-сервис (?? а может и не он)

Автор: _FRED_
Дата: 24.07.05

>закачать все темы в которых пользователь принимал участие
Например, у Влада более 30000 сообщений, и это только его сообщения, теперь можешь прикинуть количество сообщений в темах в которых он учавствовал, включая "Win vs Lin".
Так что отказать...

>закачать все темы в которых пользователь ставил оценки
Та же история, особенно учитывая, что оценки ставят гораздо чаще чем пишут сообщения.
Это все слишком большей объем, чтобы выкачать за раз, а придумывать механизм выкачивания этого дела кусками задачка не тривиальная.

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

DH>Надеятся можно?
Надейтесь..

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

_FR>>Веб-сервис (?? а может и не он)

Автор: _FRED_
Дата: 24.07.05

>>закачать все темы в которых пользователь принимал участие

M>Например, у Влада более 30000 сообщений, и это только его сообщения, теперь можешь прикинуть количество сообщений в темах в которых он учавствовал, включая "Win vs Lin".
M>Так что отказать...

Таких пользователей наберётся не больше десятка. И в первую очередь эта функция будет интересна в отношении "своих" сообщений.

>>закачать все темы в которых пользователь ставил оценки

M>Та же история, особенно учитывая, что оценки ставят гораздо чаще чем пишут сообщения.
M>Это все слишком большей объем, чтобы выкачать за раз, а придумывать механизм выкачивания этого дела кусками задачка не тривиальная.

Пользователь\Дата "От" — Дата "До".
По этим параметрам возможно выкачать подходами, зависящими от возможностей канала клиента.
Уже обсуждалось, что "Win vs Lin" — это ~5Мб — и около 5000 тысяч сообщений. Подобных топиков так же с десяток-два... И разок потерпеть, ИМХО, совсем не больно.
Ведь оценками же не только выражают отношение к сообщению, но и отмечают вниманием "нужные" топики, к которым было бы не лишне потом как-нибудь вернуться, дать на них кому-либо ссылку, попросту процитировать. Такая система гораздо гибче избранного, так как даёт больше уровней ранжирования и _намного_ быстрее позволяет выделить (для себя!) сообщение. И поэтому пользовалась бы "на ура" теми, кто какое-то время сиел в онлайне, а потом перебрался на Янус.

Можно немного разбить этот этап — с сервиса получать только идентификаторы (и идентификаторы топиков), заголовки и рейтинг сообщений пользователя и сообщений, которым он проставил оценки, а потом на клиенте дать пользователь возможность выбрать из этого то, что ему интересно и поступить с этими идентификаторами так, как сейчас работает "Reject topic". Получим гибкость и экономию за счёт рутины по отметки сообщений, которую (рутину) можно уменьшать за счёт средств клиента (убрать всё улыбки и минусы, включить все статьи, сгруппировать по коренным сообщениям, сгруппировать\отсортировать по оценкам, ...)

Блин, на запрос GetNewData тоже самое отвечает.

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

A>А чем именно?

Разница в подписке на внутренние форумы, которые д.б. недоступны обычным пользователям.

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


_FR>Таких пользователей наберётся не больше десятка. И в первую очередь эта функция будет интересна в отношении "своих" сообщений.
В top 100 рейтинга активности у 99го под 2000 сообщений. Это примерно как ручной тормоз на сервере включить.
При этом, на самом деле, функция будет интересна не только в отношении своих сообщений, а скорее в отношении широко известных людей из top-а.
Сдается мне, что, например, желающих закачать все топики Kodt-а будет гораздо больше чем желающих закачать все свои...

_FR>По этим параметрам возможно выкачать подходами, зависящими от возможностей канала клиента.
Упирается все не в канал клиента, а в сервер. Ты думаешь мы просто по прихоти своей ограничили количество выкачиваемых сообщенй 1000 при синхронизации? Нас канал клиента мало волнует, нас волнует тот факт, что когда кто-то поднимает Win vs Lin серверу плохеет.

_FR>Уже обсуждалось, что "Win vs Lin" — это ~5Мб — и около 5000 тысяч сообщений. Подобных топиков так же с десяток-два... И разок потерпеть, ИМХО, совсем не больно.
Ты это серверу объясни. Это для тебя разок, а для сервера это несколько тысяч закачек.