>>6555 я тоже думал над подобной задачей (клиент для борд), и склонился к первому варианту: общий класс борды и отдельные классы - строители для разных борд. Все-таки борды одинаковы по своей сути и отличаются только на этапе построения. По-моему правильнее разделить парсинг сайта и работу с объектом-бордой.
з.ы. Задачу так и не доделал - надоело отлаживать корректный разбор каши html

>>6557
Ну я так и начал делать. Вроде бы Ычан уже более-менее нормально грузится. Теперь нужно сделать внятный интерфейс. С этим, боюсь, я застряну надолго.

У меня следующий вопрос: как в нормальных местах работают с системой контроля версий? Т.е. такая ситуация: я хочу исправить несколько багов. Для каждого я создаю свою ветку и там его исправляю, или создаю одну ветку сразу для многих? Проблема в том, что если создать по ветке на каждый баг, то может возникнуть ситуация, что исправление одного может потом при слиянии испортить исправление другого. Или я не прав? Или я вообще не понял того, как правильно работать с системами котроля версий?

В догонку еще один вопрос. Как лучше делать сохранение избранных постов на компе? Положиться на стандартную дотнетовскую xml-сериализацию или сделать свою более читаемую, т.к. стандартная генерирует много для меня лишнего.

>>6644 не-не-не, не надо бранчить код для исправления багов. Покажу на примере SVN'а: обычная структура проекта: trunk, brunch, tags. В trunk лежит основная версия, которая редактируется и активно развивается в данный момент. В ней и надо исправлять баги, добавлять новые фичи, etc. В tags скидываются релизные на данный момент версии (например, релиз, отправленный заказчику, ну или просто успешно собранная и прошедшая тесты версия). В brunch создаются отдельные ветви проекта с особым функционалом, только если это требуется.
По поводу сохранения - решай как удобнее, у дотнета еще и бинарная сериализация есть, например

>>6648
Спасибо за разъяснения по поводу работы с системами контроля версий.
От сериализации мне нужен наиболее человеко и одновременно машинно-читаемый формат. Все же решил делать свою xml-сериализацию, т.к. с помощью LINQ2XML это делается за минут 5-10.

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

>>6650
Вопрос был о том, нужно ли создавать по ветке на каждый баг. Про Git ничего не скажу, но в ртути это не нужно, поскольку там ветви перманентны. Для внедрения небольших фич лучше использовать bookmarks или анонимные ветки. Кроме того, имхо, ветвление в любом виде стоит использовать только тогда, когда делаются изменения, которые могут поломать уже работающий функционал, и для внедрения которых требуется >1 коммита.

Сейчас делаю возможность постить на борды. Возникла проблема: почему-то у меня не ловится фаербагом пост запрос к доброчану. Какие еще есть прогаммы или плагины для фаерфокса, чтобы попробовать все же его поймать?
Или может у кого-нибудь есть исходники какой-нибудь вайпалки? Я бы взял бы код для постинга оттуда. Язык не важен, пойму любой.

>>6673
https://addons.mozilla.org/ru/firefox/addon/tamper-data

>>6674
Спасибо! Сегодня вечером попробую с этим плагином.

Писал свою реализацию форматирования данных для multipart/form-data, но как обычно сделал что-то слишком общее, абстрактное и навороченное. В итоге, забил на это и взял уже готовое решение. Правильно сделал?