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

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

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

тогда, чтоб и вешать их можно было в оффлайне

_FR>Ведь оценками же не только выражают отношение к сообщению, но и отмечают вниманием "нужные" топики, к которым было бы не лишне потом как-нибудь вернуться, дать на них кому-либо ссылку, попросту процитировать. Такая система гораздо гибче избранного, так как даёт больше уровней ранжирования и _намного_ быстрее позволяет выделить (для себя!) сообщение. И поэтому пользовалась бы "на ура" теми, кто какое-то время сиел в онлайне, а потом перебрался на Янус.

Я бы предложил синхронизацию "Избранного" Янусовского и серверного...

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

A>Жаль... но бум ждать. А то клиента надо дальше делать... а сервис не рабочий.
Вот классы, с комментариями, чтобы не скучно было:

    /// <summary>
    /// Группа форумов, для януса. 
    /// </summary>
    [Serializable]
    public class JanusForumGroupInfo
    {
        /// <summary>
        /// ID группы форумов
        /// </summary>
        [MapField("ID_ForumGroup")]
        public int forumGroupId;

        /// <summary>
        /// Имя группы форумов
        /// </summary>
        [MapField("Name")]
        public string forumGroupName;

        /// <summary>
        /// порядок сортировки
        /// </summary>
        [MapField("sortOrder")]
        public int sortOrder;
    }

    /// <summary>
    ///Описание форума, для януса.
    /// </summary>
    [Serializable]
    public class JanusForumInfo
    {
        /// <summary>
        /// ID форума 
        /// </summary>
        [MapField("ID_Forum")]
        public int forumId;

        /// <summary>
        /// ID группы форумов 
        /// </summary>
        [MapField("ID_ForumGroup")]        
        public int forumGroupId;

        /// <summary>
        /// короткое имя форума
        /// </summary>
        [MapField("shortForumName")]
        public string shortForumName;

        /// <summary>
        /// полное имя форума
        /// </summary>
        [MapField("forumName")]
        public string forumName;

        /// <summary>
        /// оценивается ли форум
        /// </summary>
        [MapField("rated")]
        public int rated;

        /// <summary>
        /// участвует ли оценки этого форума в топе 
        /// </summary>
        [MapField("InTop")]
        public int inTop;

        /// <summary>
        /// лимит оценки в форуме
        /// </summary>
        [MapField("rateLimit")]        
        public int rateLimit;
    }

    /// <summary>
    /// Данные о форуме необходимые для запроса сообщений
    /// </summary>
    [Serializable]
    public class RequestForumInfo
    {
        /// <summary>
        /// ID форума, из которого надо забрать сообщения.
        /// </summary>
        public int forumId;

        /// <summary>
        /// В первый ли раз забираются сообщения из этого форума,
        /// или пользователь уже был на него подписан ранее.
        /// </summary>
        /// <remarks>
        /// true - забираются впервые, false - уже была подписка.
        /// Если сообщения забираются впервые, то из этого форума данные 
        /// вытягиваются не по rowversion, а целиком за предыдущий день.
        /// </remarks>
        public bool isFirstRequest = false;
    }

    /// <summary>
    /// Описание сообщения, для Януса.
    /// </summary>
    [Serializable]
    public class JanusMessageInfo
    {
        /// <summary>
        /// ID сообщения. 
        /// </summary>
        public int  messageId;

        /// <summary>
        /// ID темы. 
        /// </summary>
        public int topicId;

        /// <summary>
        /// ID родительского сообщения. 
        /// </summary>
        public int parentId;

        /// <summary>
        /// ID автора.
        /// </summary>
        public int userId;

        /// <summary>
        /// ID форума
        /// </summary>
        public int forumId;

        /// <summary>
        /// Тема сообщения.
        /// </summary>
        public string subject;

        /// <summary>
        /// имя сообщения 
        /// </summary>
        public string messageName;

        /// <summary>
        /// Имя автора сообщения.
        /// </summary>
        public string userNick;

        /// <summary>
        /// Текст сообщения.
        /// </summary>
        public string message;

        /// <summary>
        /// ID статьи, если сообщение является статьей, 
        /// если же сообщение не сатья то 0. 
        /// </summary>
        public int articleId;

        /// <summary>
        /// Дата создания сообщения. 
        /// </summary>
        public DateTime messageDate;

        /// <summary>
        /// Дата обновления сообщения, если есть.
        /// Если отсутсвтует - то <see cref="DateTime.MinValue">DateTime.MinValue</see>.
        /// </summary>
        public DateTime updateDate;

        /// <summary>
        /// Статус автора сообщения.
        /// </summary>
        public UserRole userRole;

        /// <summary>
        /// Повязка пользователя. null - если отсутствует.
        /// </summary>
        public string userTitle;

        /// <summary>
        /// Цвет повязки пользователя.
        /// </summary>
        public int userTitleColor;

        /// <summary>
        /// когда в последний раз замодерировали сообщение.
        /// (действительно куда-либо преносили, а не просто вешали бомбочку)
        /// </summary>
            public DateTime lastModerated;
    }

    /// <summary>
    /// Данные для отправки сообщения в форум
    /// </summary>
    [Serializable]
    public class PostMessageInfo
    {
        /// <summary>
        /// ID родительского сообщения.
        /// </summary>
        public int parentId;

        /// <summary>
        /// ID форума.
        /// </summary>
        public int forumId;

        /// <summary>
        /// Тема сообщения.
        /// </summary>
        public string subject;

        /// <summary>
        /// текст сообщения
        /// </summary>
            public string message;
    }

    /// <summary>
    /// Бомбочки и прочая лабуда...
    /// </summary>
        [Serializable]
    public class JanusModerateInfo
    {
        /// <summary>
        /// ID сообщения на которое подвесили бомбочку.
        /// </summary>
        public int messageId;

        /// <summary>
        /// кто посмел.
        /// </summary>
        public int userId;

        /// <summary>
        /// в какой форум сносить.
        /// </summary>
        public int forumId;

        /// <summary>
        /// когда случилось.
        /// </summary>
        public DateTime create;
    }

    /// <summary>
    /// Оценки сообщений, для Януса
    /// </summary>
    [Serializable]
    public class JanusRatingInfo
    {
        /// <summary>
        /// ID оцененного сообщения
        /// </summary>
        public int messageId;

        /// <summary>
        /// ID топика оцененного сообщения
        /// </summary>
        public int topicId;

        /// <summary>
        /// ID поставившего оценку
        /// </summary>
        public int userId;

        /// <summary>
        /// рейтинг поставившего оценку
        /// </summary>
        public int userRating;

        /// <summary>
        /// Оценка
        /// </summary>
        public int rate;

        /// <summary>
        /// Время постановки оценки
        /// </summary>
        public int rateDate;
    }

    /// <summary>
    /// Поставленная оценка
    /// </summary>
    [Serializable]
    public class PostRatingInfo
    {
        /// <summary>
        /// ID сообщения, которому ставится оценка.
        /// </summary>
        public int messageId;

        /// <summary>
        /// Cобственно оценка.
        /// </summary>
        public int rate;
    }

    /// <summary>
    /// описание пользователя для януса.
    /// </summary>
    [Serializable]
    public class JanusUserInfo
    {
        /// <summary>
        /// ID пользователя
        /// </summary>
        public int userId;

        /// <summary>
        /// Имя пользователя
        /// </summary>
        public string   userName;

        /// <summary>
        /// псевдоним пользователя
        /// </summary>
        public string   userNick;

        /// <summary>
        /// реальное Имя пользователя
        /// </summary>
        public string   realName;

        /// <summary>
        /// публичное мыло пользователя
        /// </summary>
        public string   publicEmail;

        /// <summary>
        /// домашняя страница
        /// </summary>
        public string   homePage;

        /// <summary>
        /// специализация
        /// </summary>
        public string   specialization;

        /// <summary>
        /// Откудова
        /// </summary>
        public string   whereFrom;

        /// <summary>
        /// Подпись
        /// </summary>
        public string origin;
    }

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


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

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

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

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

AVK>А RSS не спасает?
не спасает, мне не нужна информация обо всех новых сообщениях. Мне нужна только информация о том, что есть ответы мне (еще возможно ответы в отмеченные мной треды). Причем это должно поедать минимум трафика, т.к. расчитано на людей у которых дорогой трафик, но которые хотят активно учавствовать в дискуссиях, быть в курсе дела и вообще оперативно реагировать в форуме.

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

S>эээ БД одна, пользователей много.

Дыр-дыр-дыр! При чём тут сервис? У него простой протокол, требующий имперсонации. Что, трудно? Так дай ему эту имперсонацию!

Твоя служба (а ля демон Линукса) при постинге с клиента должна запростить у пользователя нужные учётные данные, присовокупить к сообщению и отправить одни сообщения от одного имени, другие от другого, нужного. И так сколько там имён-пользователей. Затем запростить обновление, чтобы для всех. У нас все равны, кроме тимеров. Если хранить флаг тимерства, можно и тимеров отработать. Но вот это уже дыра, так что тимеров оставим в покое.

А если теперь посмотреть на вопрос с третьей стороны, то по сути нужен прокси-сервер, дающий доступ к одному единственному ресурсу в Сети куче людей. Может, его настроить дешевле будет?

Хочется съэкономить на 3М в сутки трафика? Тогда надо делать разбор потока сообщений. Заводить "болванчика" для получения сообщений, хранить учётку для постинга от нужного имени, сортировать сообщения в службе по форумам и выдавать пользователям в зависимости от подписанного, отрабатывать ситуации разделения, удаления и редактирования.

И это, 3М — это когда всё подписано, т.е. "для маньяков".

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

A>Либо его надо убрать ...
Уберу. Я там еще пару косяков нашел, например lastModerated по смыслу должен быть в JanusMessageInfo, а не в JanusModerateInfo.
К понедельнику постараюсь поправить (если отсюда svn работает), и наверное выложу бизнесклассы с комментариями, чтобы методом тыка не определяли что есть что...

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

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

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

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

A> сервис давай рабочий .
Готово. Глупых ошибок быть не должно, запросы, как минимум работают, вот правильно ли — это другой вопрос...
Возможно ошибся в маппинге и не все поля тянутся, но в основном все тащится.

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

WF>Пытаюсь воспользоваться новым сервисом, получаю такую ошибку от сервиса (при первой синхронизации):
Да, было такое — починил..

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

A>Т.е. отображать userNick если есть, а если нет, userName показывать?

Нет, немножко хитрее, там еще realName есть. Посмотри в янусе, там специальный метод для этого существует.

A> Или можно прям в базу писать userNmae == UserNick в случае отсутсвия одного из?

Не стоит.

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

WF>Тeперь вот такая ерунда:
Упс, все выложил, а базу поправить забыл...
Готово.

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

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

Пытаюсь воспользоваться новым сервисом, получаю такую ошибку от сервиса (при первой синхронизации):

Server was unable to process request. --> Line 25: Incorrect syntax near ')'. --> Line 25: Incorrect syntax near ')'.

Причем связано это как-то с подписыванием на форум 0 (мусорка). Меняю на

// Мусорка
forumsReq[index].setIsFirstRequest(false); // Т.е на false!

Работает. Однако при последующей синхронизации ситуацияю обратная, получаю ошибку:

Server was unable to process request. --> Line 10: Incorrect syntax near ')'. --> Line 10: Incorrect syntax near ')'.

Теперь меняю обратно, на setIsFirstRequest(true), все работает

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

Да, кстати.

M>Какие еще будут пожелания по небольшой доработке, пока руки дошли?

Ничего больше не меняй!

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

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

Огромная просьба
Обратите внимание вот на эту проблему
http://www.rsdn.ru/Forum/?mid=737849

Автор: Lloyd
Дата: 27.07.04

Очень сильно портит жизнь =((

Спасибо

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

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

Отлично! Вернусь из отпуска — переделаю свою поделку на него.

P.S. "rticleId" — опечатка?

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

M>Вообщем новый сервис януса

А в описаниях дублирование информации — это так надо? Пример:

        <Rating>
          <JanusRatingInfo>
            <messageId>int</messageId>
            <topicId>int</topicId>
            <userId>int</userId>
            <markRating>int</markRating>
            <rate>int</rate>
            <markData>int</markData>
          </JanusRatingInfo>
          <JanusRatingInfo>
            <messageId>int</messageId>
            <topicId>int</topicId>
            <userId>int</userId>
            <markRating>int</markRating>
            <rate>int</rate>
            <markData>int</markData>
          </JanusRatingInfo>
        </Rating>

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

WF>P.S. "rticleId" — опечатка?
Да, спасибо... Должно быть articleId, сегодня пофиксю, если успею.

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

A>А в описаниях дублирование информации — это так надо?
Надо.

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

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

Тут такая штука. например в GetNewUsers в wsdl есть поле

          <JanusUserInfo>
            <rowVersion>base64Binary</rowVersion>
          </JanusUserInfo>

Дык вот оно не передается.

<GetNewUsersResult>
  <lastRowVersion>AAAAAAAS3ys=</lastRowVersion>
  <users>
     <JanusUserInfo>
       <userId>22002</userId>
       <userName>fuad</userName>
       <userNick /><realName />
       <publicEmail /><homePage />
       <specialization /><whereFrom />
       <origin />
     </JanusUserInfo>
   </users>
</GetNewUsersResult>

Либо его надо убрать (подразумевая что сервис заполнит правильно поле <lastRowVersion>base64Binary</lastRowVersion>
либо передавать и клиент сам будет определять какой rowVersion был последним.

И еще, что есть этот RowVersion? long в сетевом формате? Или его надо интерпретировать просто как sequence<byte> ?

И еще , что есть userNick, а что есть userName?

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

A>Либо его надо убрать (подразумевая что сервис заполнит правильно поле <lastRowVersion>base64Binary</lastRowVersion>
A>либо передавать и клиент сам будет определять какой rowVersion был последним.

Нет, так делать нельзя. Последний rv должен определять сервер, иначе в некоторых случаях будут проблемы.

A>И еще, что есть этот RowVersion? long в сетевом формате? Или его надо интерпретировать просто как sequence<byte> ?

Его не надо вобще интерпретировать. Достаточно знать что это равномерно возрастающее 8-мибайтовое число. Обработка его на клиенте не нужна.

A>И еще , что есть userNick, а что есть userName?

Ник, это то что пишется в сообщении, а userName это логин.

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

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

A>>Либо его надо убрать (подразумевая что сервис заполнит правильно поле <lastRowVersion>base64Binary</lastRowVersion>
A>>либо передавать и клиент сам будет определять какой rowVersion был последним.

AVK>Нет, так делать нельзя. Последний rv должен определять сервер, иначе в некоторых случаях будут проблемы.
Согласен, но тогда надо из wsdl убрать . (думал может я чего не понял и он для чего-то важного нужен )

A>>И еще, что есть этот RowVersion? long в сетевом формате? Или его надо интерпретировать просто как sequence<byte> ?

AVK>Его не надо вобще интерпретировать. Достаточно знать что это равномерно возрастающее 8-мибайтовое число. Обработка его на клиенте не нужна.
Ок. будет просто long 64-ти битный.

A>>И еще , что есть userNick, а что есть userName?
AVK>Ник, это то что пишется в сообщении, а userName это логин.

Т.е. отображать userNick если есть, а если нет, userName показывать? Или можно прям в базу писать userNmae == UserNick в случае отсутсвия одного из?

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

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

A>>Либо его надо убрать ...
M>Уберу. Я там еще пару косяков нашел, например lastModerated по смыслу должен быть в JanusMessageInfo, а не в JanusModerateInfo.
M>К понедельнику постараюсь поправить (если отсюда svn работает), и наверное выложу бизнесклассы с комментариями, чтобы методом тыка не определяли что есть что...

Еще, нельзя ли отказаться от base64? Может старзу в HEX-string передавать а?. Типа lastRowId назвать (если надо кому, пусть еще и base64 идет для совместимости).

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

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

A>>Либо его надо убрать ...
M>Уберу. Я там еще пару косяков нашел, ...
Похоже багу нашел.

Я спросил:

<SOAP-ENV:Body>
 <janus1:GetTopicByMessage>
  <janus1:topicRequest>
   <janus1:userName>xxxxxx</janus1:userName>
   <janus1:password>xxxxxx</janus1:password>
   <janus1:messageIds>
     <janus1:int>123</janus1:int>
   </janus1:messageIds>
  </janus1:topicRequest>
 </janus1:GetTopicByMessage>
</SOAP-ENV:Body>

Меня послали:

  <soap:Body>
    <soap:Fault>
      <faultcode>soap:Server</faultcode>
      <faultstring>Server was unable to process request. --&gt; Column 'id' does not belong to table Forum.</faultstring>
      <detail />
    </soap:Fault>
  </soap:Body>

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

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

A>>Либо его надо убрать ...
M>Уберу. Я там еще пару косяков нашел...

 <s:element minOccurs="0" maxOccurs="1" name="subscribedForumIds" type="tns:ArrayOfJanusForumInfo"/>

по моему здесь нужно поменять на

<s:element minOccurs="0" maxOccurs="1" name="subscribedForumIds" type="tns:ArrayOfInt"/>

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

A>Похоже багу нашел.
Там таких багов... Буду править.

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

A>по моему здесь нужно поменять на
A>

A><s:element minOccurs="0" maxOccurs="1" name="subscribedForumIds" type="tns:ArrayOfInt"/>
A>

Нет.
Помимо ID форума надо знать ID последнего сообщения для каждого форума или, как минимум, был ли ранее клиент подписано на этот форум или нет.
По уму бы создать отдельную структуру, типа JanusForumRequestInfo, для запроса сообщений, но мне лень было.

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

A>Еще, нельзя ли отказаться от base64?
base64 — это не я, это web-сервис. В оригинале там byte[], как и должно быть и нормальным клиентом это вполне адекватно понимается. Так что переделывать не будем, не в строку же это дело пихать?...

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

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

A>>по моему здесь нужно поменять на
A>>

A>><s:element minOccurs="0" maxOccurs="1" name="subscribedForumIds" type="tns:ArrayOfInt"/>
A>>

А>Нет.
А>Помимо ID форума надо знать ID последнего сообщения для каждого форума или, как минимум, был ли ранее клиент подписано на этот форум или нет.
А>По уму бы создать отдельную структуру, типа JanusForumRequestInfo, для запроса сообщений, но мне лень было.
Хмм... в принципе конечно можно и так, но раз уж взялся неплохо былоб. А то косяк получается: сюда смотри, сюда не смотри, а здесь рыбу заворачивали . Если менять не будешь тогда в коменты (или даже в самом типе) напиши какие поля mandatory.

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

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

A>>Еще, нельзя ли отказаться от base64?
А>base64 — это не я, это web-сервис. В оригинале там byte[], как и должно быть и нормальным клиентом это вполне адекватно понимается. Так что переделывать не будем, не в строку же это дело пихать?...

дык какой-же там byte[] когда в janus-е есть специальный SpecialByteConverter (или как его там). Тогда может действительно лучше строку? что 8, что 16 байт, зато вопросов ни у кого не будет что это за шняга такая. (Я у себя все равно ее в строку запихнул, ибо колупаться с этими byte да еще в базу потом писать (опять же во что-то надо конвертать или в blob писать)). А то код в Janus ИМХО может и к ошибкам приводить (на память)

if(array.length() != 16)
   return new byte[8]; // Опа.  :crash:  Никакой ошибки просто RowVersion вдруг стал равен нулю.

Потом и замучаться ловить можно будет почему он все мессаги от царя гороха начал тянуть, хотя "всего лишь" lastRowVersion в конфиге например на один байт короче оказался.

Здравствуйте, 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 окетов, потом их в зависимости от базы пихать туды-сюды. Не, нафиг нафиг . По этому народ (имеется ввиду разработчики януса) особенно не заморачивась на входе/выходе его в/из строку превращают. Вот и думается мне, что если и я вынужден это же самое делать, то может перенести эту логику на сервер. Пусть сам со своими байтами разбирается, клиент будет уже строку получать.


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

Здравствуйте, 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>А чем именно?

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

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

A>Блин, на запрос GetNewData тоже самое отвечает.
Ясен байт, там один и тот же метод вызывается...

Я там все причесал, явных багов нет, и немного переделал, но выложить не могу, отсюда SVN не работает, так что скорее всего до конца недели придется потерпеть...

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

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

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

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

Убил на повал Об этом я конечно же не думал
Вопрос снимается.

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

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

A>>Блин, на запрос GetNewData тоже самое отвечает.
M>Ясен байт, там один и тот же метод вызывается...

M>Я там все причесал, явных багов нет, и немного переделал, но выложить не могу, отсюда SVN не работает, так что скорее всего до конца недели придется потерпеть...

Жаль... но бум ждать. А то клиента надо дальше делать... а сервис не рабочий.

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

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

A>>Жаль... но бум ждать. А то клиента надо дальше делать... а сервис не рабочий.
M>Вот классы, с комментариями, чтобы не скучно было:

<skip>

У меня уже есть такие на Ice . Мне сервис нужен рабочий чтоб в базу заливать начать.
Но все равно спасибо .

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

M>Какие еще будут пожелания по небольшой доработке, пока руки дошли?
Janus Notifier

Автор: SiAVoL
Дата: 25.07.05

?

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

A>У меня уже есть такие на Ice .
Они не такие, они немного другие..

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

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

A>>У меня уже есть такие на Ice .
M>Они не такие, они немного другие..

ладно зубы заговаривать сервис давай рабочий . А то руки чешуться
уже свое поделие доделать

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

S>Огромная просьба
S>Обратите внимание вот на эту проблему
S> http://www.rsdn.ru/Forum/?mid=737849

Автор: Lloyd
Дата: 27.07.04

S>Очень сильно портит жизнь =((

А что на нее обращать? Это не проблема Януса, это проблема админов. Именно они портят тебе жизнь.

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

S>>Огромная просьба
S>>Обратите внимание вот на эту проблему
S>> http://www.rsdn.ru/Forum/?mid=737849

Автор: Lloyd
Дата: 27.07.04

S>>Очень сильно портит жизнь =((

AVK>А что на нее обращать? Это не проблема Януса, это проблема админов. Именно они портят тебе жизнь.

Я бы сказал что проектирования Только не бить — предусмотреть такие... гхм... «тонкости» действительно непросто

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

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

S>>>Огромная просьба
S>>>Обратите внимание вот на эту проблему
S>>> http://www.rsdn.ru/Forum/?mid=737849

Автор: Lloyd
Дата: 27.07.04

S>>>Очень сильно портит жизнь =((

AVK>>А что на нее обращать? Это не проблема Януса, это проблема админов. Именно они портят тебе жизнь.

_FR>Я бы сказал что проектирования Только не бить — предусмотреть такие... гхм... «тонкости» действительно непросто
Ну если делается новый сервис может быть его можно было переименовать как-нибудь

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

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

При вызове getNewData получил вот такую ошибку с сервера:

Server was unable to process request. --> Cannot assign value '19.08.2005 14:32:11' of 'DateTime' type to 'JanusRatingInfo.rateDate'. Invalid cast from DateTime to Int32. --> Invalid cast from DateTime to Int32.

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

WF>При вызове getNewData получил вот такую ошибку с сервера:
Действительно, вкралась бага.
Fixed.

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

WF>>При вызове getNewData получил вот такую ошибку с сервера:
M>Действительно, вкралась бага.
M>Fixed.

Тeперь вот такая ерунда:

Server was unable to process request. --> Invalid column name 'rowversion'.
Invalid column name 'rowversion'. --> Invalid column name 'rowversion'.
Invalid column name 'rowversion'.

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

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

Про многоюзверьность

Автор: Sheridan
Дата: 23.08.05

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

S>Про многоюзверьность

Автор: Sheridan
Дата: 23.08.05

А чего там подкручивать? Без авторизации постинг невозможен, при авторизации ясно кто отправляет...

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

S>>Про многоюзверьность

Автор: Sheridan
Дата: 23.08.05

M>А чего там подкручивать? Без авторизации постинг невозможен, при авторизации ясно кто отправляет...

эээ БД одна, пользователей много. Ктото один настроен на работу с тырнетом остальные просто постят и к инету не подключаются.
Тот кто делает синхронизацию тоже постит. Как прога выяснит кто из них что запостил. В текущей версии насколько я понимаю оно просто воткнет в форум сообщения и оценки от имени синхронизирующего...

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

S> В текущей версии насколько я понимаю оно просто воткнет в форум сообщения и оценки от имени синхронизирующего...
Именно. Но если разрешить постить от имени другого, без авторизации, то это дырка, поэтому при постинге сообщений сервис должен авторизовать постящего.

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

S>> В текущей версии насколько я понимаю оно просто воткнет в форум сообщения и оценки от имени синхронизирующего...
M>Именно. Но если разрешить постить от имени другого, без авторизации, то это дырка, поэтому при постинге сообщений сервис должен авторизовать постящего.
Логично.. Гм.. В таком случае какието хеши паролей нада делать чтоли...
Иначе отрезается часть возможностей файрберда и мсскула а именно многопользховательность.
Все равно начну с этими вопросами приставать к вам когда засяду за rsdn@linux...

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


S>Логично.. Гм.. В таком случае какието хеши паролей нада делать чтоли...
Хеши и так есть, но это не слишком надежно.

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

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

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

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

Если честно... Нам бы сейчас хватило бы даже несколько в реадонли (со своими пометками прочитанного итд), один пишет и читает... И с этого можно было бы начинать плясать в общем то... ИМХО , все ИМХО

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

I> Нам бы сейчас хватило бы даже несколько в реадонли (со своими пометками прочитанного итд), один пишет и читает... И с этого можно было бы начинать плясать в общем то... ИМХО , все ИМХО
Ну это все на клиенте, сервис тут е причем.. )

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

M>Ну это все на клиенте, сервис тут е причем.. )
тогда вопрос по поводу сервиса
Я его уже поднимал — Janus Notifier

Автор: SiAVoL
Дата: 25.07.05

, но ответа не получил. Хотелось бы мнение сервисостроителей услышать. Одобрямс али нет
ЗЫ: уж больно фичи этой хочется

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

SAV>Я его уже поднимал — Janus Notifier

Автор: SiAVoL
Дата: 25.07.05

, но ответа не получил. Хотелось бы мнение сервисостроителей услышать. Одобрямс али нет

А какое это имеет отношение к Янусу? У него совершенно другая идеология. Поэтому имхо не стоит все в одну кучу сваливать.

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

A>И это, 3М — это когда всё подписано, т.е. "для маньяков".

Угу... Это про меня

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

AVK>А какое это имеет отношение к Янусу? У него совершенно другая идеология. Поэтому имхо не стоит все в одну кучу сваливать.
Но без поддержки со стороны сервера (т.е. сервиса) создание такой программы будет невозможным.

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

SAV>Но без поддержки со стороны сервера (т.е. сервиса) создание такой программы будет невозможным.

А RSS не спасает?