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

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

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

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

Здравствуйте, 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, сегодня пофиксю, если успею.

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

Да, кстати.

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

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

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

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

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

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

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

Не стоит.

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

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

Здравствуйте, 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 в конфиге например на один байт короче оказался.