jsj писал(а):edw, трудно объять необъятное... Список бесконечный. Как только воплотится хотя-бы часть этих фантазий, МЛО превратится в "урода" о которых я писал выше и его невозможно будет ни нормально поддерживать, ни нормально пользоваться.
И я с этим согласился - подход когда программа делает что-то одно, но лучше других и на любой платформе - целиком разделяю.
jsj писал(а):Уже эта ниша "как система управления задачами на основе GTD"\Автофокуса\Франклина и т.п. с межплатформенной синхронизацией самодостаточна и востребована.
Ок. Давайте назовём это так. Хотя я всегда видел в MLO только GTD, но расширение до Автофокуса\Франклина поддерживаю обеими руками.
jsj писал(а):И до сих пор не отлажены такие вещи, как математический модуль, логика с несколькими закрытыми\открытыми контекстами, автосинхронизация.
И с этим я согласен, так как эти замечания вполне вписываются в предложенную концепцию.
jsj писал(а):Поэтому я слабо верю что в такую сложную систему сможет безболезненно вписаться API или получится реализация через браузер
Вот тут не согласен. MLO действительно сложная система в своей логике поведения. Но с точки зрения данных это обычная база данных. Ничуть не сложнее чем любая другая. Забирать и добавлять данные в Cloud через API могут внешние приложения не затрагивая логику работы самого MLO.
А теперь почему именно это направление я считаю приоритетным.
Возьмём Календарь. Если он вписывается в GTD\Автофокус\Франклин он должен быть в MLO. Если не вписывается - обеспечена синхронизация с внешним календарём.
О календаре говорят очень давно. Решения по прежнему нет. И тогда возникает вопрос второго порядка - как ускорить выпуск новых версий MLO? При том, что приложение это настолько сложное, что по сути над его разработкой может работать только один человек? Напрашивается вывод - освободить этого человека от всего, что не связано с разработкой основного продукта.
Андрей уже говорил - полнофункционального календаря в MLO не будет - не вписывается он в концепцию. Значит работу по обмену данными с внешним календарём должен сделать кто-то другой, кроме Андрея.
Календари как правило держат в онлайне. Данные MLO уже так же в облаке. Именно на этом уровне логичнее строить обмен данными. Именно на эту работу логично пригласить программиста, который сможет 'этот обмен настроить. Без API, индивидуально для для 2-3 наиболее распространённых веб-сервисов календарей. И это никак не скажется на скорости внедрения тех функций, о которых говорите Вы, но облегчит жизнь многим пользователям.
Но. С Календарём всё просто - есть MLO, есть внешний календарь, нужен только скрипт. То как быть с десятками "рюшечек" которые постоянно просят пользователи? Моё предложение - один раз инвестировать деньги (подчёркиваю - не время Андрея, которого нет, а деньги) в разработку API и дальше предложить пользователям - нанимайте сами программиста и делайте со своими данными что хотите. Хоть браузерный клиент пишите. Главное что это никак не скажется ни на лаконичности и надёжности самого MLO, ни на скорости внедрения тех изменений, которые вписываются в концепцию GTD\Автофокус\Франклин.
И при этом весь процесс остаётся под контролем разработчиков через регулирование функциональности API. И при этом MLO получает новую волну пользователей через появление таких фишек как интеграция и визуализация, что должно окупить инвестиции в API.