По-сути, работы над релизом 5.5.13 еще не закончились. Сегодня добил актуализацию документации, но пока странички еще остаются помеченными как находящиеся в процессе адаптации к v.5.5.13. Эта отметка будет убираться постепенно, в последующих ревизиях. Заодно подправил информацию в презенташке "What's SObjectizer-5.5?". По-хорошему, следовало бы еще и обновить остальные презентации из серии "Deep Dive into SO-5.5", но это неслабый кусок работы и не так-то просто собраться с силами и взяться за это. Кстати говоря, еще большим уважением проникся к OpenSource проектам с хорошей и актуальной документацией.
Тем не менее, на релизе 5.5.13 жизнь проекта не останавливается, как-то нужно двигаться дальше...
До Нового Года хотелось бы успеть сделать еще одну версию, 5.5.14. Всего с одной или двумя небольшими новыми фичами. Плюс в версии 5.5.14 нужно провести ревизию входящих в состав SO-5 примеров. Полагаю, часть из них следовало бы серьезно осовременить.
Кроме того, нужно поисследовать две шутки, связанные с mchain-ами. Во-первых, возможность использования mchain-ов для защиты агентов от перегрузки. Т.е. агент выставляет наружу не свой direct_mbox, а mchain с ограничениями на размер и с определенной политикой реакции на переполнение. Например, приостановка отправителя сообщения, если mchain заполнен. С выбрасыванием либо нового сообщения, либо самого старого, если за отведенное время место в mchain-е не появилось. Ранее такого поведения штатными средствами можно было достичь только создавая пары из агента-collector-а и агента-performer-а, но при этом не было возможности "притормозить" отправителя сообщения на send-е. Теперь такая возможность есть и внимание на такой возможности нужно обязательно акцентировать (скажем, написать пример и дополнительный раздел в документации).
Во-вторых, mchain-ы, по задумке, должны упростить интеграцию SObjectizer-а в GUI-приложения. Раньше для этого требовалось создавать специальных диспетчеров, что не всегда удавалось нормально сделать (так, в свое время не удалось подружить SO-4 и FOX Toolkit из-за слишком разных подходов к контролю времени жизни объектов). Теперь, как представляется, все должно быть гораздо проще, новые диспетчеры не требуются. Нужно попробовать и посмотреть, так ли это. Собственно, в связи с этим вопрос к читателям: может ли кто подсказать простую задачку, в которой нужен несложный GUI и какая-то многопоточная логика? Чтобы можно было эту логику оформить в виде SObjectizer-овских агентов, общающихся с GUI-овой частью через mbox-ы и mchain-ы.
Всего вышеперечисленного уже хватит на две-три недели работы, если все делать вдумчиво и качественно. А там уже можно и стартовать работы над версией 5.6.0, в которой планируется выбросить кучу deprecated вещей и забить на поддержку Visual C++ 12.0.
Кроме того, может иметь смысл добавить в 5.6.0 еще что-нибудь существенное. Но здесь уже вопрос упирается в то, в какую сторону вообще должен развиваться SO-5. У меня есть собственное мнение о том, что SO-5 должен быть максимально непохожим на CAF/Akka/Erlang... Есть так же и некий перечень вещей, которыми следует заниматься для развития SO-5. Если кому-нибудь интересно, могу выставить этот список на всеобщее обозрение и обсуждение. Хотя сомневаюсь, что кто-нибудь откликнется.
В качестве послесловия к релизу 5.5.13 могу сказать, что этот релиз очень четко показал разницу между работой "для удовольствия" и работой "потому, что есть такое слово -- надо". И еще лучше осознать, сколько же труда было вложено в этот, по сути, совсем маленький проектик. Жаль, что у меня нет коммерческой жилки. Для будущего SO-5 было бы лучше, чтобы его дальнейшей судьбой занимался толковый маркетолог, а не конструктор велосипедов, вроде меня...
Напоследок хочу высказать слова благодарности Николаю Гродзицкому, Николаю Шмакову, Алексею Сырникову, Борису Сивко и Денису Томашенко за помощь в подготовке очередной версии SObjectizer-а: огромное вам спасибо!
Комментариев нет:
Отправить комментарий