Да, очень нужен | 72% - 208 | |||||
Вместо диспетчера вполне хватает загрузки заголовков | 16% - 47 | |||||
Нет, не нужен | 10% - 30 | |||||
|
Создание графического интерфейса для управления приёмом почты с почтового сервера.
Речь ведь не только о графическом интерфейсе идёт, но о новом функционале, нет?
Не думаю, что разумно делать это для приёма сообщений сразу со всех учётных записей почты.
Индивидуальной работы с каждой учётной записью имхо должно быть достаточно.
Может быть. А может быть и нет. Надо проверять.
В теме пишут про желательность отображения первых нескольких строк.
Согласен.
"загрузить и удалить на сервере"
Вариант «загрузить» именно это и предполагает.
"пометить как прочтённые"
Даже так, два варианта: «оставить на сервере (как прочтённые)», «оставить на сервере (как непрочтённые)»
Это называется запрос на изменение - фичереквест
Тогда уж «Feature request».
Отсутствует
MySh
Речь ведь не только о графическом интерфейсе идёт, но о новом функционале, нет?
Создавать графический интерфейс не подкреплённый функционалом как-то странно.
А если будет соотв код, но не будет ГУИ - кто этим будет пользоваться?
Тогда уж «Feature request».
фичереквест
Ищем 10 отличий
Короче это сленг.
--- ---
Отсутствует
Хотелось бы почётче очертить границы т.н. "диспетчера писем". Если не говорить про анлим, не говорить про IMAP (кстати, у меня ящик на mail.ru, и есть странное ощущение, что IMAP там просто не работает. Да и в разделе помощи про IMAP ни слова), не говорить про привычки, то получается вот что.
Мы имеем две точки сбора писем: локальную (свой комп, коммуникатор или что-то ещё, что всегда под рукой) и удалённую (почтовый сервис - gmail.com, mail.ru и т.п.).
Исходя из этого, возникают две задачи: контроль почты на удалённой точке и синхронизация локальной точки с удалённой.
То есть, необходимо иметь возможности:
1. Стереть ненужные письма с удалённой точки, не загружая их.
2. Получить некоторые нужные письма на локальную точку, при этом оставив их на удалённой.
3. Получить некоторые нужные письма на локальную точку, при этом стерев их с удалённой.
4. Стереть некоторые письма с локальной точки, оставив их на удалённой.
5. Стереть некоторые письма с локальной точки, уничтожив их и на удалённой.
(Извините, что так подробно, просто хочется получше структурировать свои мысли.)
Нужность писем определяется отдельным интерфейсом (дата, размер, наличие вложений, первые строки и т.п.). Управление процессом тоже немного вываливается из стандартной процедуры получения писем Тандербёрда. Поэтому потребуется что-то типа батовского окошка. Стандартный список входящих писем не подходит, потому что получается шизофрения: в одном списке письма на удалённой точке, на локальной точке, удалённые там, оставленные здесь... Совместить всё это без потерь эргономичности - большая проблема.
Работа с заголовками в Громоптице не предполагает такой сложной схемы, а только поддерживает идею проекции удалённой точки на локальную. Отсюда и требования анлима, поскольку проекция тут простейшая: что на удалённой точке, то и на локальной (опция "оставлять письма на сервере" не очень удачная, и выглядит скорее как костыль). Проблемы, приносимые примитивностью, компенсируются технической мощью анлима. Но мощь не всегда доступна, да и примитивная работа с почтой не всем пригодна.
Примерно так. Спасибо за внимание.
Отредактировано akastargazer (28-03-2009 01:38:35)
Отсутствует
1. Стереть ненужные письма с удалённой точки, не загружая их.
2. Получить некоторые нужные письма на локальную точку, при этом оставив их на удалённой.
3. Получить некоторые нужные письма на локальную точку, при этом стерев их с удалённой.
Как раз про это я и говорил.
4. Стереть некоторые письма с локальной точки, оставив их на удалённой.
5. Стереть некоторые письма с локальной точки, уничтожив их и на удалённой.
А вот это уже задача клиента, а не диспетчера писем.
Кстати, есть мысль, что хорошо бы как-то различать те письма, которые пришли только что, и те, которые уже до этого пришли, но были отложены до следующего сеанса связи (без прочтения) — так меньше вероятность пропустить что-то важное и срочное.
Отсутствует
У клиента есть папка "Входящие". Это содержимое локальной точки. А диспетчер помогает управлять процессом появления писем в папке "Входящие". Управление письмами в папке "Входящие" - это всего лишь вопрос клиентского интерфейса с делегированием некоторых функций диспетчеру.
Другими словами, если хочется удалить письмо в папке "Входящие", и одновременно удалить его на сервере - тут без диспетчера не обойтись.
Диспетчер - это всего лишь набор функций, обращение к которым происходит из клиента.
P.S. С пропущенными\отложенными письмами классная идея. Это всё к тому же тонкому управлению своей почтой!
Отредактировано akastargazer (29-03-2009 14:54:18)
Отсутствует
akastargazer
если хочется удалить письмо в папке "Входящие", и одновременно удалить его на сервере - тут без диспетчера не обойтись.
Зачем для этого диспетчер?
Достаточно галочки об удалении/оставлении писем на сервере при удалении писем на клиенте.
Диспетчер - это всего лишь набор функций, обращение к которым происходит из клиента.
Сам диспетчер - тот же самый клиент.
--- ---
Отсутствует
akastargazer
если хочется удалить письмо в папке "Входящие", и одновременно удалить его на сервере - тут без диспетчера не обойтись.
Зачем для этого диспетчер?
Достаточно галочки об удалении/оставлении писем на сервере при удалении писем на клиенте.
Да, но в каком месте ставить эту галочку? И в какой момент? Если надо, допустим, с утра синхронизировать удалённую и локальную точки, то все 5 вышеописанных операций лучше делать в одном месте - окошке диспетчера. Если через неделю оказывается, что нужно почистить локальную точку (с воздействием на удалённую), то удобнее работать с папкой "Входящие".
Сам диспетчер - тот же самый клиент.
Не соглашусь. Диспетчер - это всего лишь функциональный блок клиента.
Ещё хочется сказать про плагины. Идея плагинизации, конечно, очень привлекательная, но на деле получается не так радужно. Есть масса примеров, когда разработчик плагина не следит за развитием головной программы и в результате, плагин протухает. Поэтому, я считаю, функциональный блок под условным названием "Диспетчер писем" должен быть встроен в базовую конфигурацию Thundebird, а не перекладываться на плагин. Это было бы наилучшим и перспективным решением. Ну а прототип, лабораторный образец - вполне можно сделать как плагин.
Про участие. Я б взялся за разработку, но в силу некоторых обстоятельств, не могу в течение минима полугода делать предположений о свободном времени для таких вещей. Думаю, у других уважаемых участников обсуждения такая же ситуация, поэтому предлагаю пока сформулировать требования, обрисовать характеристики и выработать план разработки.
Если "диспетчер" всё-же появится в виде плагина, то проект должен быть максимально открыт для желающих поддержать разработку и спасти её от протухания. Как его открывать и как поддерживать - тоже можно обсудить.
Отсутствует
Идея плагинизации, конечно, очень привлекательная, но на деле получается не так радужно. Есть масса примеров, когда разработчик плагина не следит за развитием головной программы и в результате, плагин протухает. Поэтому, я считаю, функциональный блок под условным названием "Диспетчер писем" должен быть встроен в базовую конфигурацию Thundebird, а не перекладываться на плагин. Это было бы наилучшим и перспективным решением
Осталось только убедить в этом разработчиков...
Если "диспетчер" всё-же появится в виде плагина, то проект должен быть максимально открыт для желающих поддержать разработку и спасти её от протухания.
Разумеется, так и должно быть. В принципе, расширения обычно открыты.
Отсутствует
Это всё понятно, только вот если у нас есть несколько ящиков, и на один, например, приходит мало, но вообще писем там много, а на второй наоборот, можно получить такую нехорошую ситуацию:
1. Приём почты - показывать только новые: первый ящик будет готов к работе очень быстро, зато второй мб готов существенно позже. Что делать? Ждать готовность от всех? Тогда может получиться общая большая задержка. Или подгружать по мере готовности? Тогда это всё надо будет грамотно синхронизировать + периодически всё будет дёргаться обновляясь;
2. А теперь мы снимем галочку Только новые - получаем обратную ситуацию с торможением (причем уж тут оно мб весьма значительным, так как сообщений на сервере может храниться на порядки больше, чем просто приходить).
То есть получается, что работать с ящиками индивидуально удобнее (и проще в реализации), чем в совокупности.
Аналогично можно прийти к такому же выводу и для папок.
То есть получается, что делать такой диспетчер вообще говоря не очень хорошая идея.
Мб разумнее развить функциональность Загружать только заголовки сообщений, а с картиной в целом работать как-то иначе?
Например с помощью фильтров (никогда не пробовал - мб так и неудобно работать - но тогда надо либо доработать фильтры, либо создать новый инструмент).
А чтобы работать с письмами на сервере достаточно, чтобы просто отображалась дублирующая структура папок (вроде и сейчас через IMAP такое наблюдается - так мб просто и для POP3 это сделать?..).
Просто если вместо диспетчера можно предложить какой-то другой механизм работы с письмами на сервере, который можно было бы проще реализовать, а тем более в ключе текущего развития - шансы реализации на самом высоком уровне возрастут.
--- ---
Отсутствует
Не совсем понимаю логическую цепочку, приводящую к выводу "с папками надо работать так же, как с ящиками". Ящик - это удалённая точка, папки - это локальная точка. Сущности разные, задачи разные, принципы работы разные.
Как работает диспетчер писем, можно посмотреть в том же TheBat!. Работает прекрасно, пользоваться удобно, сделано для людей - есть на что посмотреть и есть чему поучиться. Но и там кое-чего не хватает.
А "заголовки писем" - это кастрированная схема, которуя я описал выше, или другими словами, костыль.
Отредактировано akastargazer (31-03-2009 02:16:49)
Отсутствует
akastargazer
Не совсем понимаю логическую цепочку, приводящую к выводу "с папками надо работать так же, как с ящиками". Ящик - это удалённая точка, папки - это локальная точка
Я про папки на сервере.
Хотя не уверен, что через POP3 эти папки видно.
Как работает диспетчер писем, можно посмотреть в том же TheBat!.
Когда-то сам пользовался.
Но и там кое-чего не хватает.
Чего?
--- ---
Отсутствует
Мои рассуждения отталкиваются от следующего соображения: письма перетекают с удалённой точки на локальную. Какие там папки - неважно. Если надо хранить письма на сервере, то смысла обсуждать диспетчер нет.
Лично мне надо контролировать обе точки (и удалённую, и локальную) так, как я хочу - то есть, максимально удобно. Удобство выражается в том числе и в выделении некоторой функциональности клиента в отдельный блок. В Бате уже есть такое выделение, но там не хватает п.п. 4,5 и отложенных писем. Это тоже задача диспетчирования писем, в смысле связи локальной и удалённой точек.
Отсутствует
akastargazer
...В Бате уже есть такое выделение, но там не хватает п.п. 4,5 и отложенных писем...
4. Стереть некоторые письма с локальной точки, оставив их на удалённой.
5. Стереть некоторые письма с локальной точки, уничтожив их и на удалённой.
В БАТе это можно сделать, но не в Диспетчере, а манипулируя следующими параметрами:
Отсутствует
Да, возможно. Фишка в том, чтобы не бегать каждый раз в настройки.
Отсутствует
Это должно удовлетворять всем перечисленным здесь разумным требованиям
Нужно реализовать ГУИ для управления почтой на почтовом сервере (УПС).
Основные требования:
1. Отображение списка всех почтовых сообщений из папки на почтовом сервере, с почтового сервера, с нескольких почтовых серверов в соответствии с указанной пользователем детализацией, сортировкой и фильтрацией;
2. Возможности по детализации кроме заголовков сообщений включают статус новизны сообщения: новое, непрочитанное, отсутствует на клиенте, присутствует на клиенте -, размер сообщения, наличие вложений и их название, тип и размер, а также начало письма с возможностью указания числа символов/строк;
3. Сортировка, фильтрация и поиск по всем выводимым столбцам;
4. Над всеми/выбранными/отфильтрованными почтовыми сообщениями проводятся следующие операции:
скопировать/переместить на почтовый клиент (эквивалентно простому приёму почты), удалить с почтового клиента и/или с почтового сервера, изменить статус причитанности сообщения;5. В случае загрузки писем на почтовый клиент выводить подробную информацию о процессе: какое сообщение/вложение сейчас загружается, насколько загрузилось/сколько осталось, общий прогресс.
Желательные требования:
6. Возможность назначить использование УПС как основного способа приёма почты для конкретного почтового ящика.
--- ---
Отсутствует
Вах! Круто!
Чует моё сердце, что разработчики скажут что-то вроде "используйте функцию получения заголовков" За судьбой данного запроса как-нить можно следить онлайн?
Отсутствует
Forest
Вроде бы есть всё, что нужно.
Чует моё сердце, что разработчики скажут что-то вроде "используйте функцию получения заголовков"
Тогда придётся писать «в "Спортлото"»...
Отсутствует
Опубликовал Feature request - Bug 488001 - теперь надо за него как можно больше голосов набрать!
Для этого сначала надо зарегистрироваться в Bugzilla (если уже не зарегистрированы конечно).
А потом воспользоваться ссылкой vote в строке Importance (появится список, в котором будет "Enter New Vote here 488001 Feature request: The mail control GUI for mailserver creating (Show Votes)", поставить галочку и нажать на Change My Votes.
Если все отметившиеся в голосовалке проголосуют и там, у разработчиков будет хороший повод для размышлений
--- ---
Отсутствует
pi.v.vitaly
Ты так уверен в этом?
"Попытка не пытка" (с)
А вообще выше я писал, что хочется по крайней мере понять реакцию разработчиков на это, так как мне пока так никто и не подтвердил, что до их сведения эту идею кто-нибудь доводил.
Вот если реакции не будет/будет негативная - тогда можно будет дальше думать.
--- ---
Отсутствует
Проголосовал
Отсутствует
Вот и первая реакция:
--- Comment #1 from Ludovic Hirlimann (:_Tsk_) <ludovic@mozillamessaging.com> 2009-04-12 08:19:11 PDT ---
so you want to be able to control your mail server from thunderbird , is that what you are asking for ?
Вопрос-то концептуально неточный, потому что TB и так уже позволяет контролировать письма на сервере (опция "удалять письма с сервера"). Вопрос в расширении и уточнении функциональной нагрузки.
Отсутствует
Wave
Ну там ещё пытаются спорить.
Опять же остаётся таинственный mozilla.dev.extension - осталось понять что это и как туда попасть?..
--- ---
Отсутствует
Непонятно другое - тут голосовали 131 человек, на bugzilla - 5 (включая меня)
Получается, что все споры и вопли о небходимости диспетчера писем на проверку оказались обычным холиваром? Несерьёзно как-то!
Было бы больше голосов, может и к предложению отнеслись бы внимательнее, имхо.
Отредактировано 68agasfer (13-04-2009 23:10:15)
Arch Linux & xmonad
Отсутствует
68agasfer, за какое время проголосовали тут и за какое время проголосовали там?
А кроме того, почему бы там не дать ссылку на это голосование, чтобы разработчики увидели 70% поддерживающих идею и почти пару сотен проголосовавших за два с лишним года.
Отсутствует