Pull to refresh

Comments 44

Неплохо. Возьму на заметку. Лицензия?
GPL, в конце статьи не ярко, но написано
Ух. пропустил :) Теперь вижу.
А какая из версий? Они там довольно сильно различаются, особенно в части серверных приложений.
Например: Нужно ли открывать код пользователям сайта, на котором работает ваше приложение?
На github достаточно заглянуть: GNU GPL v3 или более новая, на ваш выбор.
не знаю, укажите где нибудь ссылку на github, а там изменяйте как хотите и не показывайте кода. Я на вас не буду в суд подавать пока вы не скажите, что ваше это всё )))
Да при чём тут суд?
Вот пишу я веб-приложение для заказчика, надо встроить простенькую почту, возьму я вашу программу.
Мне GPL не страшен в любой форме — исходники заказчику я всё равно предоставляю полностью.
Но вот придёт какой-нибудь пользователь этого веб-приложения и скажет, а раз у вас тут GPL, то давайте мне исходники вашего приложения!
Поэтому-то и спросил, нужно ли открывать код пользователям по ту сторону браузера.
Нет. Они пользуются результатами работы PHP-кода, а не самим кодом. А JS-код, который они запускают у себя, им предоставлен.

AGPL заставляет делиться исходниками и с пользователями сервиса, GPL не заставляет.
Ну, так и вы, запуская на своём компьютере GNU/Linux пользуетесь результатами работы Си-кода, а не самим кодом. Но GPL даёт вам право получить код. А предоставленный JS-код (как и HTML и CSS) может быть банально пожат для ускорения загрузки — т.е. как-то скомпиллирован из понятного разработчику в понятный браузеру. И он может генерироваться динамически PHP-кодом (и наоборот, хы-хы). И без PHP-кода не иметь практического смысла. Там мутный момент с вебприложениями, и есть почти неуловимая (для меня) разница между версиями GPL (AGPL, LGPL, GPLv2, GPLv3).
Я пользуюсь Си-кодом представленном в другом виде. GPL даёт мне право получить оригинал. Но на вход и выход этого кода поступает информация, GPL о ней ничего не говорит.
Если ваш GPL-код жёстко привязан к другому коду (не может без него работать), то по идее этот другой тоже должен быть GPL-совместим.
Я не против использования моего приложения в составе другого. Но вот в GPL я профан.
Если мне нужна лицензия для коммерческих продуктов, мне помогает юрист составить нужные документы. С общественными лицензиями серьёзного дела не имел, если вам интересно использовать продукт в своих целях, можете мне помочь указать верную лицензию на код.
Apache в ту же сторону.
А нагрузочное тестирование проводилось?
нет, и в принципе, на очень большую нагрузку приложение не рассчитано. Много запросов к БД. Для личного использования проблемы нет, если использовать проект в компании, как корпоративную почту, сильно больших проблем с производительностью тоже не должно быть. Тем более всегда можно сделать портицирование в БД. Делать приложение доступным для кучи людей в интернете не стоит.
Позже я планирую заняться производительностью
Это же не МетаПочта :)
да… жаль что не получилось довести её до конца
А для не планшетников планируете подправить интерфэйс?
В принципе да, это интересная задача. Только не подправить интерфейс под ПК, а сделать поддержку тем оформления, чтобы сделать мобильный и десктопный интерфейс сменными.
Просто немного раньше, у почтовика был интерфейс похожий на the bat!

А потом, как-то вдруг, он стал таким как сейчас.
Ну я сказал именно подправить, так как на скажем моем андроид устройстве с экраном 4.3" все выглядит супер за исключением пары косяков, но думаю ваша идея с темами оформления для этого подойдет лучше.
Классная штука!
Возможность изменить шаблон ответа будет?)
Ага, шаблоны у меня в списках todo. Если, честно, то и подписи к сообщениям я сделал совсем недавно, чтобы разнообразить возможности почтовика к статье на хабре.
Это не самые сложные вещи для реализации, а потому они и остаются, как обычно, на потом.
созданное без фреймворков
с помощью MVC
Дальше не читал. Что же тогда по ссылке, если не фреймворк?
Ухтыж! Спасибо Вам добрый человек… я только сегодня утром с ужасом подумал что я собираюсь отказаться от тандерберда, забирать почту фечмаилом и смотреть через веб) а тут практически изкаробочное решение!
Ага, именно: fetchmail + procmail + roundcube я использовал раньше. Но так, как это всё крутится на домашнем сервере, а там я периодически всё переустанавливаю, после очередной переустановки OS решил попробовать написать своё. А roundcube, конечно же, хорош.
Не подскажете, roundcube при каждом обновлении веб-страницы дергает почтовый сервак или есть какое-то кеширование?
не могу сказать, но какого-либо кеширования там не видел.
Огромные плюсы roundcube — хороший интерфейс и конечно же стабильность. Минус — only imap и хранение писем в виде файлов. Хотя письмо — файл, это проще. В моём почтовике письмо хранится в БД, а перед этим оно преобразуется в html. Для разбора структура письма есть готовые решения, но я пытался сделать без зависимостей.
очень хорошо, но я пробежался по почте и не нашел нужного письма. Меня интересует работа с inline-графикой, как будут отображаться письма от к примеру одноклассников, когда картинки не в виде ссылок на хост, а в виде ссылок на бинарное изображение в теле письма
inline отображается в виде аттачей. Это я планирую доработать в следующих версиях. Так что не стоит воспринимать почтовик, как завершённый продукт, что явно указано в топике "Приложение пока ещё достаточно сырое", главное увидеть заинтересованность в приложении. Для себя я могу допиливать что-то бесконечно долго, но если нравится людям — есть аргументация. Тем более github не запрещает содействовать в развитии почтовика.
Еще один велосипедист.
Roundcube получше будет и всем устраивает.
Несколько странностей (мож у меня чего глючит, [FF10, NoScript по такому случаю выключен, ABP включен])
1. Где бы я ни был, «Back» всегда (не всегда, только при просмотре писем) выкидывает в главное окно с перечнем всех писем. Это просто караул. Однако при однократном нажатии на кнопку «Возврат к списку» история вообще стирается (тоже не всегда) и поведение по возврату становится совсем другим.
2. Ссылки на адресах отправителя/получателя почему-то уводят на мой локальный мэйлер, типа «mailto: ...»
3. Кликнутое поле затрагивает весь ряд, в то время как, ховер не накрывает чекбокс.
4. При нажатии кнопки «проверить» (я так понял это принять/отправить) на полсекунды выскакивает некое окно, моргает красными надписями «ошибка!» и прячется. Стесняется видимо. Если уж ошибка, могло бы и подождать.
5. Добавление нового почтового ящика не работает

Из мелких придирок (можно не обращать внимания)
1. редактирование папок и контактов сильно растянуто, одно окно, потом второе, потом еще… Если уж вы решили использовать яву, то может закинуть это все в одно место? (окно в смысле :)
2. А ну их, эти мелочи. Все равно там еще многое поменяется :)

А так, впечатление очень приятное, такой мягкий минимализм, как то, что требуется от почты и даже чуть-чуть больше.
1. Ну кнопкой «Back» пользоваться не стоит. Загрузка письма происходит Ajax-запросом внутрь фрейма. А значит перезагрузки страницы не происходит, кнопка «вернуться к списку», делает фрейм невидимым, показывая список сообщений.
Отсюда два вывода: истории просмотра сообщений там нет, т.к. нигде не хранится id текущего письма, и второй надо мне сделать какое-то «адекватное» действие на кнопку «Back» браузера же.
2. Да, старая проблема, мне просто всегда лень было убрать эти mailto: и сделать обработку внутри приложения
3. Там поле сообщения теоритически разбито на две части:
1) рядом с checbox-ом, выделяет сообщение, но не выполняет переход к просмотру письма, нужно чтобы с клавиатуры можно было бы выбирать нужное письмо
2) остальная часть — справа. Выполняет переход к просмотру письма.
Вывод: подумать на юзибилити и интерфесом, чтобы всё было логичнее.
4. Ошибка вызвана тем, что не получается забрать сообщения :) Мне нужно сделать debug mode, где подробно вывести текст ошибки. Вам смотреть логи и проверить наличие нужных модулей php и чтобы файрвол не закрывал нужные порты. А мне, получается, сделать красивый инсталятор.
5. В demo версии я же добавлял как-то ящики. Буду проверять.

Ну а к остальному, да интерфейс и юзабилити. Мне приятно, что несмотря ни на что у вас сложилось приятное впечатление о приложении. Буду исправлять, чтобы в ближайшее время сделать красивше и удобнее.
3. mouseover тоже можно растянуть на два элемента (у вас наверное через CSS, поэтому и разъехалось). А вообще, если уж делается подсветка по клику, то чекбох может и не нужен… Мультиклики вполне терпимо смотрятся (дело вкуса конечно), но они все равно лучше видны, чем чекбокс. имхо. С ними конечно возни чуть побольше и задержки растут. Особенно когда select all.
3а. У вас paginator-a нет? А зря. Т.е. он необходим с абсолютной уверенностью (я лично его не люблю, но без него никак)
4. Я немного о другом. Когда получаешь письма, смотришь на открывшееся окно коннекта и когда все нормально, про него сразу забываешь. А вот если ошибка, то всегда нужно видеть что там не так и почему, т.е. закрывать его автоматически наверное не надо. Или по крайней мере с приличной задержкой и последующей красной надписью об ошибках.
Ошибка сервера: запись в директорию невозможен.
спасибо, исправил
1. Список папок бы слева всегда иметь.
2. Кнопку отправить продублировать бы вверху — чтоб не скроллить лишний раз при пересылке письма (понапокупали, блин «прямоугольных» мониторов)

Где можно подписаться на обновления движка?
Вот понесло-то меня:
3. Кнопку проверить убрать! Почта должна появляться сразу как приходит.
4. Кнопками перемещается — хорошо, Enter-ом в письмо не заходит
5. Список папок слева — нужен. Чтоб drag-n-drop-пить туда письма, и переходить в папки одним кликом (Вы попробуйте тётеньке у Вашего клиента по телефону объяснить, что она должна нажать на кракозябру справа от кнопки Папки (причем делать она это будет «даблкликом»)
6. Столбцы таблицы (дата, тема, от) по клику — сортировка (мгновенная)
У как, даже.
1) Но тут уже почти решил сделать поддержку тем, и сделать две темы — для десктопа с папками слева (как на картнке где-то в комментах) и для мобильного вида.
2) А что за кнопка «отправить»? 0_о
Кстати, да, кнопка «Переслать» нужна, её нет, знаю, не сделал.
3) Почта, если честно, умеет проверяться автоматически по крону, в проекте даже есть папка /cron/, которая занимается проверкой новой почты. Но на момент статьи, я немного поленился проверить всё и не выложил её на github. Исправлю.
4) ну логика тут есть…
5) Нажимать не надо, там надо мышь подвести и меню само покажется. (см. пункт 1)
Drag`n`drop писем в папках конечно же нужен, но совсем не в первую очередь.
6) надо да.
Обновлений движка не задумывалось, отдельно движка как проекта нет, для меня это всего лишь «каркас» откуда можно делать новые приложения. Тут возникла диллема: продолжать делать проект также или перенести его на YII.
2) кнопка отправить — в форме создания/пересылки письма
7) Предпросмотр вложений (как это делает mail.ru — через microsoft office live, или как яндекс — через что-то свое, причем часто неудачно) — киллефича — не надо сохранять вложение чтоб посмотреть пару цифр в присланном «эксэльчике».
Мне на ум пришло «универсальное» решение: вложение распространенных типов файлов открывается на виртуальной машине, делается скриншот и кладется в базу вашего web-почтовика. Пользователю показывается скриншот, т.о. часто можно заранее понять, стоит ли вообще скачивать вложение.
8) скачать все вложения одним архивом (на майлру работает но архив всегда называется одинаково — видимо программиста сократили)
левый список это конечно стандарт, да. Но возня с ним конца не имеет, имхо на этом этапе лучше даже не начинать. Это типа версия 1.1 (как и драг-дроп)
Подскажите, а чем обусловлен выбор jhtmlarea? (нет, это не придирка, просто интересно мнение).
1) он легче чем, ckeditor и tinymce.
2) Нужен именно html редактор, а не BB.
3) Он jquery

Если можете посоветовать, что-то получше, буду рад.
Sign up to leave a comment.

Articles