Здравствуйте, m.a.g., Вы писали:
MAG>Нашел некоторое количество свободного времени. Есть над чем поработать?
Конечно! Вопрос в твоем классе и серьезности задачть которые ты можешь решать.
Например нужно (очень нужно) менять Веб-сервис. Там нужно добавить бинарную сериализацию датасетов и сжатие. Так же нужно добавить обработку удалений на основе лога (например, у нас вообще не работает удаление оценок).
Есть и более независимая задача. Нужно создать прокси-сервер. Этот сервер должен быть с одной стороны клиентом севриса на rsdn.ru, а с другой строны предоставлять такой же интерфейс (Веб-сервис). При этом сервер должен складывать запросы на обновление, кэшировать результат и отдавать, при запросх, данные из кэша. Данные лучше всего хранить в mssql (точнее в MSDE).
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Например нужно (очень нужно) менять Веб-сервис. Там нужно добавить бинарную сериализацию датасетов и сжатие. Так же нужно добавить обработку удалений на основе лога (например, у нас вообще не работает удаление оценок).
Вот с сервисом вряд ли — сервис доступен по понятным причинам только группе.
Здравствуйте, VladD2, Вы писали:
VD>Кстати, как мне самому этот сервер локально запустить? А то я чувствую, что не дождусь кгда вы сериализацию бинаргую с сжатием подключити.
Это не ко мне, я сайтом не занимаюсь.
... << RSDN@Home 1.1 alpha 1 (np: The Cranberries — Dying In The Sun) >>
Здравствуйте, AndrewVK, Вы писали:
VD>Кстати, как мне самому этот сервер локально запустить? А то я чувствую, что не дождусь кгда вы сериализацию бинаргую с сжатием подключити.
AVK>Это не ко мне, я сайтом не занимаюсь.
Ну, а как ты сервис отлаживаешь? Мне именно он нужен.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Кстати, как мне самому этот сервер локально запустить? А то я чувствую, что не дождусь кгда вы сериализацию бинаргую с сжатием подключити.
Хм... Проще чем новый Хоум...
Уфф... упарился, пока завел, пришлось форум "прочее" грохнуть руками в аксесе, чтобы он базу корректно обновил.
Плюс еще обнаружил забавный глюк, при выставлении в настройках времени пометки сообщения как прочитанного в ноль, при просмотре сообщений вылетает эксепшен, мол фигня случилась, надо как минимум еденицу.
Вот кстати по поводу запустить локально есть маленький req.: Вынести куда-нибудь в настройки, чтобы он не на rsdn.ru лез, а в то место куда ему укажешь...
А что касается сайта, то когда с CVS'а возьмешь, там есть каталог DOC, и в нем все что нужно для настройки... Ну почти.
Здравствуйте, Merle, Вы писали:
M>Вот кстати по поводу запустить локально есть маленький req.: Вынести куда-нибудь в настройки, чтобы он не на rsdn.ru лез, а в то место куда ему укажешь...
Прикрутим. Можешь кстати сам и прикрутить.
M>А что касается сайта, то когда с CVS'а возьмешь, там есть каталог DOC, и в нем все что нужно для настройки... Ну почти.
А в ЦВС какой путь?
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, m.a.g., Вы писали:
MAG>>Нашел некоторое количество свободного времени. Есть над чем поработать?
VD>Из мелкой работы можно, например, сделать сартировку по разным полям и вариантам в главном дереве. Ну, там по оценкам, по пользователю...
VD>В поиск можно добавить поиск за определенный промежуток дат.
Насчет сортировки. Сортировать будет клиент дерева (перед установкой Nodes)?
Здравствуйте, VladD2, Вы писали:
VD>Конечно! Вопрос в твоем классе и серьезности задачть которые ты можешь решать.
Там посмотрим. Я свои умения оценивать никак не научусь — своя оценка обычно оказывается гораздо того, как меня оценивают окружающие.
VD>Например нужно (очень нужно) менять Веб-сервис. Там нужно добавить бинарную сериализацию датасетов и сжатие. Так же нужно добавить обработку удалений на основе лога (например, у нас вообще не работает удаление оценок).
За это я, наверное, не возьмусь пока.
VD>Есть и более независимая задача. Нужно создать прокси-сервер. Этот сервер должен быть с одной стороны клиентом севриса на rsdn.ru, а с другой строны предоставлять такой же интерфейс (Веб-сервис). При этом сервер должен складывать запросы на обновление, кэшировать результат и отдавать, при запросх, данные из кэша. Данные лучше всего хранить в mssql (точнее в MSDE).
Здравствуйте, m.a.g., Вы писали:
VD>>Есть и более независимая задача. Нужно создать прокси-сервер. Этот сервер должен быть с одной стороны клиентом севриса на rsdn.ru, а с другой строны предоставлять такой же интерфейс (Веб-сервис). При этом сервер должен складывать запросы на обновление, кэшировать результат и отдавать, при запросх, данные из кэша. Данные лучше всего хранить в mssql (точнее в MSDE).
MAG>А вот это вполне можно сделать.
Здравствуйте, VladD2, Вы писали:
VD>Есть и более независимая задача. Нужно создать прокси-сервер. Этот сервер должен быть с одной стороны клиентом севриса на rsdn.ru, а с другой строны предоставлять такой же интерфейс (Веб-сервис). При этом сервер должен складывать запросы на обновление, кэшировать результат и отдавать, при запросх, данные из кэша. Данные лучше всего хранить в mssql (точнее в MSDE).
Кстати, насколько я понимаю, писать эту штуку с нуля будет жутким оверхэдом. Синхронизация Януса отрывается легко и перенастраивается на прокси, чувствую, что с сервисом будет та же штука. Проблема в том, что после этого получится по две реализации как веб-сервиса, так и клиента, которые поддерживать в синхронизованном состоянии будет достаточно трудно. Так что нужно рассмотреть вопрос выделения из Януса кода сериализации в отдельный проект и из сайта — вебсервиса. Тогда их можно будет достаточно просто сшить вместе и получить то, что надо.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, VladD2, Вы писали:
VD>>А в ЦВС какой путь? M>:/rsdn — а дальше кажется без путей....
нифига source а потом — на корне синхронизуйся и он дернет все остальные модули
... << RSDN@Home 1.1 alpha 1 >>
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
Здравствуйте, VladD2, Вы писали:
VD>Из мелкой работы можно, например, сделать сартировку по разным полям и вариантам в главном дереве. Ну, там по оценкам, по пользователю...
VD>В поиск можно добавить поиск за определенный промежуток дат.
Здравствуйте, Merle, Вы писали:
M>Вот кстати по поводу запустить локально есть маленький req.: Вынести куда-нибудь в настройки, чтобы он не на rsdn.ru лез, а в то место куда ему укажешь...
Здравствуйте, WFrag, Вы писали:
WF>Насчет сортировки. Сортировать будет клиент дерева (перед установкой Nodes)?
Нет. Сортировать нужно не в памяти, а запросом. В будующем скорее всего придется делать более оптимальную загрузку. Ну, грузить первые 100-300 тем, а остальнеые или подкачивать в быкграунде, или по требованию (кодга пользователь начнет просматривать невидимые ему по началу темы). Так что сортировать нужно именно в запросе. Для этого нужно канкатинировать к запросу на выборку тем имена колонок по которым производить сортировку, ну, и DESC/ASC (порятод сортировки). Естественно, что передавать порядок нужно в виде некого энума. Да... передавать нужно в метод LoadData класса Msg.
Еще один вопрос в том как получать и отображать направление сортировки. В большинстве случаев получать можно путем обработки клика на колонке. Но вот, например, с датами так не прйдет. Дело в том, что самый удобный спостоб (используемый сейчас) — это сортировка по дате последнего обновления (она лежит в поле topic_info.answers_last_update_date) причем эта дата не отображается в гриде. Можно конечно заложиться на обработку поля дата, но при этом неясно как получить желание отсортировать по дате создания темы.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, m.a.g., Вы писали:
MAG>Кстати, насколько я понимаю, писать эту штуку с нуля будет жутким оверхэдом. Синхронизация Януса отрывается легко и перенастраивается на прокси, чувствую, что с сервисом будет та же штука. Проблема в том, что после этого получится по две реализации как веб-сервиса, так и клиента, которые поддерживать в синхронизованном состоянии будет достаточно трудно. Так что нужно рассмотреть вопрос выделения из Януса кода сериализации в отдельный проект и из сайта — вебсервиса. Тогда их можно будет достаточно просто сшить вместе и получить то, что надо.
MAG>Кстати, в чем на сервере хранятся данные? MSSQL?
Да. Причем формат БД отличается от формата локальной базы. Да и работать придется с данными отплевыемыми сервером. Так что общего кода там не будет. Ну, или будет очень мало.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, m.a.g., Вы писали:
VD>>Есть и более независимая задача. Нужно создать прокси-сервер. Этот сервер должен быть с одной стороны клиентом севриса на rsdn.ru, а с другой строны предоставлять такой же интерфейс (Веб-сервис). При этом сервер должен складывать запросы на обновление, кэшировать результат и отдавать, при запросх, данные из кэша. Данные лучше всего хранить в mssql (точнее в MSDE).
MAG>А вот это вполне можно сделать.
Давай. А то у нас до него руки еще долго не дойдут.
MAG>Только тогда давайте модуль в CVS и логин
Дадим. Только я тут не компетентен. Заведи новую ветку. Назови ее "Прокси". И в качестве одного из вопросов задай вопрос о логине. Завтра появятся зубры ЦВС-а и сделают тебе логин.
Вообще-то если ты будешь заниматься этим делом, но наверное будет лучше включить тебя в группу (ты ведь как я понимаю еще не вней?). Тогда тебе будет доступны исходники сервера и возможность прямого общения с девелоперами сайта.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
VD>А мне сайт и нафиг не упал. (Хотя ИТ вроде рассказывал как это дело запускать.)
AVK>Так сервис без сайта не живет
Это что же там такого? Я тут со всех сторон слышу, что Хоум гад лезет в БД напрямую. Что же он цепляет если к БД он лезет сам?
PS
БД у меня работает.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Покажи. А вообще, чтобы меньше зависить от сервера нужно пользоваться параметрами. За исключением функций mssql понимает почти весь SQL от JET-а.
Здравствуйте, VladD2, Вы писали:
VD>Еще один вопрос в том как получать и отображать направление сортировки. В большинстве случаев получать можно путем обработки клика на колонке. Но вот, например, с датами так не прйдет. Дело в том, что самый удобный спостоб (используемый сейчас) — это сортировка по дате последнего обновления (она лежит в поле topic_info.answers_last_update_date) причем эта дата не отображается в гриде. Можно конечно заложиться на обработку поля дата, но при этом неясно как получить желание отсортировать по дате создания темы.
Я бы предпочел чтобы клик по колонке приводил к появлению выпадающего меню с пунктами нет, возраст., убыв.. У дат понятное дело пункты другие. ИМХО так даже удобнее чем стандартный клик по колонке.
Здравствуйте, VladD2, Вы писали:
VD>Это что же там такого? Я тут со всех сторон слышу, что Хоум гад лезет в БД напрямую.
Он лезет напрямую там где на момент написания не было промежуточного слоя. Списки форумов, права пользователя, добавление сообщений делается через библиотеки сайта.
Здравствуйте, AndrewVK, Вы писали:
AVK>Я бы предпочел чтобы клик по колонке приводил к появлению выпадающего меню с пунктами нет, возраст., убыв.. У дат понятное дело пункты другие. ИМХО так даже удобнее чем стандартный клик по колонке.
Лишние движения тоже вредны. Думаю меню есть смысл добавить только к дате (ну, и другим не однозначным пунктам).
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
AVK>>Я бы предпочел чтобы клик по колонке приводил к появлению выпадающего меню с пунктами нет, возраст., убыв.. У дат понятное дело пункты другие. ИМХО так даже удобнее чем стандартный клик по колонке.
VD>Лишние движения тоже вредны.
Ты так часто меняешь порядок сортировки? Да и не сильно оно больше там движений — контекстное меню обычно показывают в непосредстьвенной близости от курсора. Зато то что из за случайного клика по заголовку, который находится рядом с другими кликоактивными элементами управления происходит изменение сортировки меня достает.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ты так часто меняешь порядок сортировки?
У тебя подход не конструктвный. Часто тут не причем. Например, я пароль и путь к БД задают только когда конфиг слетает. Но почему-то ты вынес его в настройку и не заставляешь лазить черти где, а потом перезагружать программу. Тут нужно подходить так. Лишние движения вредны априори. Их наличие нужно очень серьезно обосновать. Тогла приложение будет получаться удобным.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
MAG>>Кстати, в чем на сервере хранятся данные? MSSQL?
VD>Да. Причем формат БД отличается от формата локальной базы. Да и работать придется с данными отплевыемыми сервером. Так что общего кода там не будет. Ну, или будет очень мало.
Ничего не понимаю. Берется с сервера веб-сервис. Вставляется синхронизация с главным сервисом периодически/по входящему соединению. Код синхронизации берется из януса, чуток поколбасить SQL-запросов — не беда Получается прокси.
Здравствуйте, VladD2, Вы писали:
VD>Дадим. Только я тут не компетентен. Заведи новую ветку. Назови ее "Прокси". И в качестве одного из вопросов задай вопрос о логине. Завтра появятся зубры ЦВС-а и сделают тебе логин.
VD>Вообще-то если ты будешь заниматься этим делом, но наверное будет лучше включить тебя в группу (ты ведь как я понимаю еще не вней?). Тогда тебе будет доступны исходники сервера и возможность прямого общения с девелоперами сайта.
Да, это будет самое то (см. мое предыдущее сообщение).
Здравствуйте, m.a.g., Вы писали:
MAG>Ничего не понимаю. Берется с сервера веб-сервис. Вставляется синхронизация с главным сервисом периодически/по входящему соединению. Код синхронизации берется из януса, чуток поколбасить SQL-запросов — не беда Получается прокси.
Так тут вроде говорили, что вебсервис пол-сервера за собой потянет.
Здравствуйте, WFrag, Вы писали:
MAG>>Ничего не понимаю. Берется с сервера веб-сервис. Вставляется синхронизация с главным сервисом периодически/по входящему соединению. Код синхронизации берется из януса, чуток поколбасить SQL-запросов — не беда Получается прокси.
WF>Так тут вроде говорили, что вебсервис пол-сервера за собой потянет.
Здравствуйте, m.a.g., Вы писали:
MAG>Ничего не понимаю. Берется с сервера веб-сервис. Вставляется синхронизация с главным сервисом периодически/по входящему соединению. Код синхронизации берется из януса, чуток поколбасить SQL-запросов — не беда Получается прокси.
Прокси нужен не для того чтобы он был, а для того чтобы кешировать трафик. Вот это то и нужно реализовать.
Здравствуйте, m.a.g., Вы писали:
AVK>>Прокси нужен не для того чтобы он был, а для того чтобы кешировать трафик. Вот это то и нужно реализовать.
MAG>Это понятно. Берется с сервера веб-сервис с базой данных...
Ответ неправильный. В отличие от сервера прокси не доступна серверная БД. Пополнять свою локальную БД он может только при запросах пользователей, к нему подключенных. Главная хитрость в тмо чтобы те запросы, которые попали в локальную БД отдавать пользователю сразу, а те что не попали просить по инету. При этом не забывать о том что содержимое кеша может устареть.
Здравствуйте, m.a.g., Вы писали:
MAG>Ничего не понимаю. Берется с сервера веб-сервис. Вставляется синхронизация с главным сервисом периодически/по входящему соединению. Код синхронизации берется из януса, чуток поколбасить SQL-запросов — не беда Получается прокси.
Ну?! Это все код из Хоума. Сервер то тут причем?
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ответ неправильный. В отличие от сервера прокси не доступна серверная БД. Пополнять свою локальную БД он может только при запросах пользователей, к нему подключенных.
Ну, это не свосем верно. Можно и по таймеру. У сервера должен быть собственных логин (админа).
AVK> Главная хитрость в тмо чтобы те запросы, которые попали в локальную БД отдавать пользователю сразу, а те что не попали просить по инету. При этом не забывать о том что содержимое кеша может устареть.
Что значит устареть? Если прийдут изменения, кэш обновится. Все равно данные будут отдаваться после синхронизации.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>У сервера должен быть собственных логин (админа).
Вот это то и не очевидно. Ну очень не хочется никаких левых юзеров, поскольку это дырка.
VD>Что значит устареть? Если прийдут изменения, кэш обновится. Все равно данные будут отдаваться после синхронизации.
А если данные уже в кеше — клиенту они отдадуться именно оттуда, а на сервере эти данные могут к тому моменту уже измениться.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, VladD2, Вы писали:
VD>>У сервера должен быть собственных логин (админа).
AVK>Вот это то и не очевидно. Ну очень не хочется никаких левых юзеров, поскольку это дырка.
VD>>Что значит устареть? Если прийдут изменения, кэш обновится. Все равно данные будут отдаваться после синхронизации.
AVK>А если данные уже в кеше — клиенту они отдадуться именно оттуда, а на сервере эти данные могут к тому моменту уже измениться.
А как Янус запрашивает данные? Говорит дай от этого номера и до конца? Тогда прокси при запросе от клиента все равно всегда должен синхронизоваться с сервером. Вот тут-то он и получит изменения.
Здравствуйте, WFrag, Вы писали:
WF>А как Янус запрашивает данные? Говорит дай от этого номера и до конца? Тогда прокси при запросе от клиента все равно всегда должен синхронизоваться с сервером. Вот тут-то он и получит изменения.
ПРоблема в том что у разных клиентов могут быть разные точки предыдущей синхронизации.
Здравствуйте, AndrewVK, Вы писали:
AVK>Вот это то и не очевидно. Ну очень не хочется никаких левых юзеров, поскольку это дырка.
Тут оно как. Если получится обойтись без левых юзверей, то конечно луше без них. Но может оказаться, что все же с админом будет удобнее. Ну, а дыркой это не является. Или же дырой фвляется весь хоум. Что собственно страшного, что админ будет запускать сервер под своим паролем?
AVK>А если данные уже в кеше — клиенту они отдадуться именно оттуда, а на сервере эти данные могут к тому моменту уже измениться.
Еще раз повторяю:
При запросе на обновление будет делаться синхронизация кэша, и он всегда будет актуальным.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Тут оно как. Если получится обойтись без левых юзверей, то конечно луше без них.
А в чем проблема?
VD>Но может оказаться, что все же с админом будет удобнее. Ну, а дыркой это не является. Или же дырой фвляется весь хоум. Что собственно страшного, что админ будет запускать сервер под своим паролем?
А если у админа не будет никаких особых прав тогда зачем он вобще нужен? Чем не устраивает текущий пользователь?
Здравствуйте, AndrewVK, Вы писали:
VD>Тут оно как. Если получится обойтись без левых юзверей, то конечно луше без них. AVK>А в чем проблема?
Спроси того кто будет это делать. Грабли обычно становястя отчетливо видны только после наступания на них.
AVK>А если у админа не будет никаких особых прав тогда зачем он вобще нужен? Чем не устраивает текущий пользователь?
А сервер кто будет подымать? Один хрен тот кто подымает сервер потенциально может читать данные всех пользователей (ему же кэш доступен).
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, AndrewVK, Вы писали:
VD>>Тут оно как. Если получится обойтись без левых юзверей, то конечно луше без них. AVK>>А в чем проблема?
VD>Спроси того кто будет это делать. Грабли обычно становястя отчетливо видны только после наступания на них.
AVK>>А если у админа не будет никаких особых прав тогда зачем он вобще нужен? Чем не устраивает текущий пользователь?
VD>А сервер кто будет подымать? Один хрен тот кто подымает сервер потенциально может читать данные всех пользователей (ему же кэш доступен).
Точно, с одной стороны... с другой — надо две версии прокси иметь... одна — для RSDN Team, имеет доступ к внутренним форумам.. вторая — для "просто Корпораций", которая в принципе не имеет доступа к внутренним форумам
... << RSDN@Home 1.1 alpha 1 >>
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, AndrewVK, Вы писали:
AVK>>ПРоблема в том что у разных клиентов могут быть разные точки предыдущей синхронизации.
VD>Да какая разница? Они всегда будут читать кэш. И точки у них будут по кэшу.
Да, а если один юзер синхронизует форумы 1 и 2, например? Прокси у себя синхронизует эти форумы, но форум три он не синхронизует (например, это закрытый форум). Получается, форум три — не синхронизован. Решение, конечно, есть — для каждого форума держать свой lastMsgId, и синхронизовать их отдельно.
Здравствуйте, WFrag, Вы писали:
WF>Да, а если один юзер синхронизует форумы 1 и 2, например? Прокси у себя синхронизует эти форумы, но форум три он не синхронизует (например, это закрытый форум). Получается, форум три — не синхронизован. Решение, конечно, есть — для каждого форума держать свой lastMsgId, и синхронизовать их отдельно.
Или так. Или вообще тащить версии записей и делать синхронизацию на их основе.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Мы уже победили, просто это еще не так заметно...
.
Берется с сервера веб-сервис. Вставляется синхронизация с главным сервисом периодически/по входящему соединению. Код синхронизации берется из януса, чуток поколбасить SQL-запросов — не беда 