YAM - Yet Another Mailer: Ticket Queryhttp://yam.ch/query?status=!closed&type=task&order=id
The Open-Source Amiga E-mail suiteen-USYAM - Yet Another Mailerhttp://yam.ch/chrome/site/yam.gifhttp://yam.ch/query?status=!closed&type=task&order=id
Trac 1.0.6.post2http://yam.ch/ticket/122
http://yam.ch/ticket/122#122: User-definable toolbarsFri, 05 Mar 2010 23:22:06 GMTdamato<p>
Now that since YAM 2.5 is using TheBar.mcc, the configuration of YAM should allow each user to define which toolbar buttons to display and which to hide. And of course also in which order they should be displayed.
</p>
Resultshttp://yam.ch/ticket/122#changeloghttp://yam.ch/ticket/123
http://yam.ch/ticket/123#123: User-definable context menusFri, 05 Mar 2010 23:23:24 GMTdamato<p>
All context menus should be user configurable. That means, user should be able to configure which menu items to link to a context menu in case the right mouse button is pressed on e.g. a mail item.
</p>
Resultshttp://yam.ch/ticket/123#changeloghttp://yam.ch/ticket/124
http://yam.ch/ticket/124#124: Rework/Improvement of mailing-list functionalityFri, 05 Mar 2010 23:25:03 GMTdamato<p>
The current mailing-list feature of YAM is more than just plainly useless and unintuitive. Currently a user has to configure a mailing list by creating a new folder and configuring the mailing list settings in the folder settings. This, however, seems to be somewhat awkward and not very intuitive and cumbersome.
</p>
<h2 id="Proposedchange">Proposed change</h2>
<p>
A possible change/improvement could be:
</p>
<ul><li>move the folder-wise mailing list configuration to the global YAM config window (own section)
</li><li>a user should be able to configure a mailing list in the YAM config using the following settings:
<ol><li>configure mailing list address (To)
</li><li>configure if a mailing list sets a Reply-To: header or not (important for proper Mail-Reply-To support).
</li><li>set an optional destination folder where incoming mails should be moved to (this should generate hidden filter rules to move the mail to that folder based on To, etc. address)
</li><li>allow to setup the above settings semi-automatically like currently possible in the folder settings.
</li></ol></li><li>the Mail-Reply-To and Mail-Followup-To features should respect these new configuration settings.
</li><li>the mailing-list To-addresses should be suggested when creating a new mail and entering something in the To recipient gadget
</li><li>when starting to create a new mail while being in a folder linked to a particular mailing list the write window should immediately contain the To address of that mailing list in the To recipient gadget.
</li></ul>Resultshttp://yam.ch/ticket/124#changeloghttp://yam.ch/ticket/125
http://yam.ch/ticket/125#125: Completly reworked address book GUIFri, 05 Mar 2010 23:31:17 GMTdamato<p>
The addressbook itself needs a completly rework <acronym title="Graphical User Interface">GUI</acronym> as in its current form it is very hard to use it on a daily basis. It should be reworked to allow for entering all kind of information on a more uptodate state (like in Thunderbird) such that e.g. all LDIF information can be more properly be fit in.
</p>
<p>
In addition, the maintainer of that task should care about compatibility to CManager and try to use the CManager MCC instead of reinventing the wheel once again. That means, it should be first tested if CManager can replace our own addressbook implementation even if that means that work on CManager should be done instead.
</p>
Resultshttp://yam.ch/ticket/125#changeloghttp://yam.ch/ticket/126
http://yam.ch/ticket/126#126: HTML read mail supportFri, 05 Mar 2010 23:33:41 GMTdamato<p>
A direct <acronym title="Hyper-Text Markup Language">HTML</acronym> reading engine should be integrated/used in YAM instead of only converting <acronym title="Hyper-Text Markup Language">HTML</acronym> mails to plain text via our own <acronym title="Hyper-Text Markup Language">HTML</acronym>2text engine.
</p>
<p>
In fact, such a feature should use a third-party MCC like htmlview.mcc or any otehr appropriate <acronym title="Hyper-Text Markup Language">HTML</acronym> viewing engine. However, especially for using htmlview.mcc, further porting/work on that component itself have to be done before we can consider using it as our <acronym title="Hyper-Text Markup Language">HTML</acronym> reading engine in YAM.
</p>
<p>
Also with that change we should take care not to generally use that <acronym title="Hyper-Text Markup Language">HTML</acronym> viewing engine but allow the user to select how he wants to view <acronym title="Hyper-Text Markup Language">HTML</acronym> mails and if we need that <acronym title="Hyper-Text Markup Language">HTML</acronym> reading engine at all.
</p>
Resultshttp://yam.ch/ticket/126#changeloghttp://yam.ch/ticket/130
http://yam.ch/ticket/130#130: S/MIME supportFri, 05 Mar 2010 23:45:05 GMTdamato<p>
Besides the wanted GnuPG support for signing/encrypting messages, a future version of YAM should also probably consider implementing S/MIME. The current uptodate <a class="acronym" href="http://www.ietf.org/rfc.html"><acronym title="IETF Request For Comment">RFC</acronym></a> for S/MIME can be found here:
</p>
<p>
<a class="ext-link" href="http://tools.ietf.org/html/rfc5751"><span class="icon">​</span>http://tools.ietf.org/html/rfc5751</a>
</p>
<p>
Mailers like Thunderbird already support S/MIME and it seems together with AmiSSL such an S/MIME functionality can be implemented quite straight forward.
</p>
Resultshttp://yam.ch/ticket/130#changeloghttp://yam.ch/ticket/132
http://yam.ch/ticket/132#132: Implement a stronger password encryption mechanismsFri, 05 Mar 2010 23:47:14 GMTdamato<p>
YAM should be changed to use a significantly improved password encryption mechanism. Currently, the passwords in all config files are more or less unencrypted (almost no real encryption). Idially YAM should get a master/slave password mechanism similar to what is implemented in Thunderbird. That means, all passwords and sensitive information in the config files will be encrypted with a master password that is stored in a separate file.
</p>
Resultshttp://yam.ch/ticket/132#changeloghttp://yam.ch/ticket/134
http://yam.ch/ticket/134#134: Add "Stop" Toolbar button which aborts e.g. filteringFri, 05 Mar 2010 23:49:47 GMTdamato<p>
As soon as we have implemented the user-definable toolbars we ought to add a "Stop" toolbar button in case there is some action in progress which might be able to be aborted (e.g. filtering, index scanning etc.)
</p>
Resultshttp://yam.ch/ticket/134#changeloghttp://yam.ch/ticket/135
http://yam.ch/ticket/135#135: Rework internal Error handler (window) to be a notification agentFri, 05 Mar 2010 23:51:31 GMTdamato<p>
The Error handling mechanism (e.g. ER_NewError(), YAM_ER.c) should be reworked to achieve the following things:
</p>
<ol><li>Introduce a difference between "Errors" and "Warnings" so that YAM might notify the user of things that are of minor priority (e.g. images missing, decoding failure of main mail part, etc.)
</li><li>Rename the whole Error mechanism into a more general "Notification" service/agent thingy.
</li><li>The notification/error window should be changed to contain two areas to present the pending notifications: On the left side a listview with the summary of the pending notifications. On the right a floattext object with the actual message of the notification.
</li><li>Warnings/Errors should be directly differentated via graphical images in the listview. Pending notifications should be bold.
</li><li>Add a functionality to send notifications that won't automatically popup the notification window but show a sign (e.g. in the window bar of YAM) in case minor warnings are shown.
</li></ol>Resultshttp://yam.ch/ticket/135#changeloghttp://yam.ch/ticket/137
http://yam.ch/ticket/137#137: Replace flex-based scanner with re2c based oneFri, 05 Mar 2010 23:54:42 GMTdamato<p>
There seems to be a new, faster and easier scanner engine out there which looks quite promising. Even the <acronym title="Hypertext Preprocessor">PHP</acronym> people seem to have switched from a flex-based scanner to a re2c based one. Therefore it might be worth a look.
</p>
<p>
See here for more information: <a class="ext-link" href="http://re2c.org/"><span class="icon">​</span>http://re2c.org/</a>
</p>
<p>
It also supports the CONDITION support which we are using in our flex-based scanners, thus it should be relatively easy to use re2c instead of flex <img src="/chrome/emoticons/wink.png" alt=";)" class="emoticon" width="18" height="18" style="vertical-align: middle" />
</p>
Resultshttp://yam.ch/ticket/137#changeloghttp://yam.ch/ticket/142
http://yam.ch/ticket/142#142: Hidden config editor in YAM configuration GUIFri, 12 Mar 2010 13:41:29 GMTdamato<p>
To allow users to edit the hidden (expert) configuration options from within the YAM configuration <acronym title="Graphical User Interface">GUI</acronym> a possibility should be provided to do that with graphical elements. Instead of providing graphical elements for each single hidden option a generic config edit can be provided by simply putting a listview in the config <acronym title="Graphical User Interface">GUI</acronym> which carries columns for the name, a description and the value. Then this entry could be editable.
</p>
<p>
However, as soon as a user would like to open that config edit tool a warning requester should be presented. This functionality would more or less work similar to what Thunderbird or Firefox provides when editing "about:config".
</p>
Resultshttp://yam.ch/ticket/142#changeloghttp://yam.ch/ticket/312
http://yam.ch/ticket/312#312: Investigate possibility to use sqlite for mail indexing/storingSat, 02 Jun 2012 22:22:58 GMTdamato<h2 id="Phenomenon">Phenomenon</h2>
<p>
Currently YAM saves each mail in a separate file using an index file to quickly find mail throughout the filesystem. It might be, however, a better approach to use perhaps an <acronym title="Structured Query Language">SQL</acronym> based approach (e.g. using 'sqlite').
</p>
<h2 id="Backgroundanalysis">Background analysis</h2>
<p>
On AmiNET there exists an amiga port of sqlite 3.6.1 (<a class="ext-link" href="http://aminet.net/package/biz/dbase/sqlite-3.6.1-amiga"><span class="icon">​</span>http://aminet.net/package/biz/dbase/sqlite-3.6.1-amiga</a>) which might be a good basis for a test.
</p>
<h2 id="Implementationrecommendation">Implementation recommendation</h2>
<p>
A prototype have to be created where several thousands emails should be stored and indexed in a basic <acronym title="Structured Query Language">SQL</acronym> database using sqlite. Performance tests against the current solution should be made and based on these performance tests the prototype should be converted into code usable for YAM (or not).
</p>
Resultshttp://yam.ch/ticket/312#changeloghttp://yam.ch/ticket/318
http://yam.ch/ticket/318#318: Add "Quick-Reply" feature to read window (readmailgroup)Sat, 02 Jun 2012 23:11:05 GMTdamato<h2 id="Phenomenon">Phenomenon</h2>
<p>
It would be favourable if the read window would have a "Quick-Reply" possibility where the user could quickly enter some multi-line text and press "Send" to send out a direct reply to the currently displayed mail. This would allow to send a reply without having to open a full write window, etc.
</p>
<h2 id="Implementationrecommendation">Implementation recommendation</h2>
<p>
A small TextEditor.mcc object have to be added on demand to the bottom of the read window for that purpose with two buttons "Send" and "Cancel". The original text should be quoted in there like in a normal write window reply action. But no attachment possibility presented.
</p>
Resultshttp://yam.ch/ticket/318#changeloghttp://yam.ch/ticket/319
http://yam.ch/ticket/319#319: Complete overhaul of global configuration implementationSat, 02 Jun 2012 23:21:43 GMTdamato<h2 id="Phenomenon">Phenomenon</h2>
<p>
The current configuration soley relies on a global "struct Config" structure which is directly accessed from throughout the whole YAM source code. This has several drawbacks and should be completely changed.
</p>
<h2 id="Backgroundanalysis">Background analysis</h2>
<p>
First of all the current configuration source code (including the <acronym title="Graphical User Interface">GUI</acronym> part) should be changed into an internal MUI custom class (using GenClasses). Then struct Config should be abadoned and instead accessor and mutator functions be added to retrieve and set the values of a certain config option (e.g. via string-based config option names). Furthermore, the configuration structure should carry information about the type (boolean, integer, string, etc.) of the variable so that the Load and Save config function can interate through this structure getting rid of the tons of "else if()" branches currently implemented in YAM_COs.c.
</p>
<h2 id="Implementationrecommendation">Implementation recommendation</h2>
<p>
Take care of:
</p>
<ul><li>Custom classes
</li><li>Hash tables uses
</li><li>Black box approach
</li></ul>Resultshttp://yam.ch/ticket/319#changeloghttp://yam.ch/ticket/322
http://yam.ch/ticket/322#322: UpdateCheck mechanism should allow to also directly install updatesSun, 03 Jun 2012 15:52:29 GMTdamato<h2 id="Phenomenon">Phenomenon</h2>
<p>
To finalize the UpdateCheck mechanism it should be possible to not only download the latest update archive directly. It should also be possible to install the update right away seeing YAM being closed, the updated files/binaries updated and then YAM being restarted to finalize the update.
</p>
<h2 id="Backgroundanalysis">Background analysis</h2>
<p>
While for a simple updatecheck mechanism downloading the update lha archive might be enough a better approach would be if the update could also be automatically installed instead of just downloading the archive and relying on the user to install the update properly. Several major problems with that approach seem to prevent the implementation however:
</p>
<ol><li>We have to find a way to close YAM remotely (e.g. via ARexx) and restart it after the files from the update archive were installed.
</li><li>We have to standardize the update archive to also be able to handle larger update jumps (e.g. if a YAM 2.8 user want to update to YAM 3.0 directly without having to install 2.9 first)
</li><li>We have to take care not to overwrite files that have been changed by the user (e.g. by using md5sum or similar)
</li><li>How should third-party updates (e.g. mcc classes, etc.) be treated?
</li></ol><h2 id="Implementationrecommendation">Implementation recommendation</h2>
<p>
An ideal implementation would present an "Install Update" button instead of "Download" in the update notification window. If the user presses this button YAM will be closed, the update installed (possibility non-interactive, with creating backups, etc.) and afterwards YAM being restarted to finalize the update.
</p>
Resultshttp://yam.ch/ticket/322#changeloghttp://yam.ch/ticket/464
http://yam.ch/ticket/464#464: Restructure folder tree loading processWed, 27 Nov 2013 08:39:01 GMTtboeckel<h2 id="Phenomenon">Phenomenon</h2>
<p>
Currently (YAM &lt;= 2.9) the folder tree and the individual folder configurations are loaded after the global configuration. Since certain elements of configuration (i.e. <acronym title="Simple Mail Transfer Protocol">SMTP</acronym> sent folder, <acronym title="Post Office Protocol">POP3</acronym> incoming folder, filters, user identity sent folder) are referencing folders by ID it is currently impossible to resolve the folder IDs immediately while loading the configuration.
</p>
<h2 id="Implementationrecommendation">Implementation recommendation</h2>
<p>
The folder tree loading process should be split into two parts:
</p>
<ol><li>Load the folder tree only, but no individual folder configuration yet, to make the folders globally available.
</li><li>Load the individual folder configurations
</li></ol><p>
This will make it possible to resolve any folder ID immediately while loading the global configuration. The individual folder configurations (i.e. max mail age, mailing list support, etc) are not needed at that early stage. When the folder configurations are eventually loaded their references to the global configuration (signature, user identity) can also be easily resolved, as the global configuration is fully set up then, too.
</p>
Resultshttp://yam.ch/ticket/464#changeloghttp://yam.ch/ticket/467
http://yam.ch/ticket/467#467: Change build environment to use 'cmake'Wed, 04 Dec 2013 08:57:36 GMTdamato<h2 id="Phenomenon">Phenomenon</h2>
<p>
Currently our build environment uses a plain Makefile with only very limited possibilities to automatically identify build relevant changes/differences between users (e.g. different installation paths, etc.). Thus, it would be good to change our build environment in future to use something like 'autoconf' or 'cmake' to make it possible to automatically generate the Makefile based on some rules defined there.
</p>
<h2 id="Backgroundanalysis">Background analysis</h2>
<p>
autoconf support seems to be somewhat impossible or hard to achieve. In addition, 'cmake' seems to provide a more modern and easier to implement interface which will allow us to be also be potentially directly used in a native (AmigaOS) build since binaries exist also for at least OS4.
</p>
<h2 id="Implementationrecommendation">Implementation recommendation</h2>
<p>
Before 'cmake' will be implemented a prototype should be generated by opening a separate svn branch to evaluate if full 'cmake' is really possibly or if there is still a show-stopper for using 'cmake' in our build environment.
</p>
Resultshttp://yam.ch/ticket/467#changeloghttp://yam.ch/ticket/567
http://yam.ch/ticket/567#567: Implement an account setup wizardMon, 02 Jun 2014 06:48:49 GMTtboeckel<h2 id="Phenomenon">Phenomenon</h2>
<p>
It has been mentioned quite often that setting up a new account in YAM is too complicated due to its amount of adjustable options.
</p>
<h2 id="Backgroundanalysis">Background analysis</h2>
<p>
Mail clients on other systems offer a setup wizard where you just have to enter your name, email address and password and the mail client will obtain all the other settings (i.e. <acronym title="Post Office Protocol">POP3</acronym> and <acronym title="Simple Mail Transfer Protocol">SMTP</acronym> server name, port number, security settings, etc) automatically so that the (possibly unexperienced) user has to care about as less stuff as possible.
</p>
<h2 id="Implementationrecommendation">Implementation recommendation</h2>
<p>
Implement a setup wizard similar to the one of Thunderbird. The "beginners" mode just requires the basic things like name, address and password. A possible "advanced" mode then offers editing some more details like server address, port number, etc just like the normal config window does.
</p>
Resultshttp://yam.ch/ticket/567#changeloghttp://yam.ch/ticket/583
http://yam.ch/ticket/583#583: IMAP 'download' supportThu, 18 Sep 2014 22:22:59 GMTdamato<h2 id="Phenomenon">Phenomenon</h2>
<p>
Since the <acronym title="Internet Message Access Protocol">IMAP</acronym> protocol is a lot more complex than the <acronym title="Post Office Protocol">POP3</acronym> protocol, it is also a lot more complicated to implement full <acronym title="Internet Message Access Protocol">IMAP</acronym> synchronization support in short time. To be able to provide some first basic <acronym title="Internet Message Access Protocol">IMAP</acronym> support to users a stripped down <acronym title="Internet Message Access Protocol">IMAP</acronym> support should be implemented (so-called '<acronym title="Internet Message Access Protocol">IMAP</acronym> download') which should work essentially the same like the <acronym title="Post Office Protocol">POP3</acronym> protocl. That means it should only download emails and provide functionality like simple <acronym title="Post Office Protocol">POP3</acronym> download support.
</p>
<h2 id="Backgroundanalysis">Background analysis</h2>
<p>
For this to be implemented, the <acronym title="Internet Message Access Protocol">IMAP</acronym> protocol needs to be analyzed so that only a few commands are used to list new waiting emails, to extract UIDL identifiers and to download new emails. All other functionality such as synchronizing the read status, etc. should be kept for the upcoming full <acronym title="Internet Message Access Protocol">IMAP</acronym> support in YAM 3.0+.
</p>
<h2 id="Implementationrecommendation">Implementation recommendation</h2>
<p>
When implementing this '<acronym title="Internet Message Access Protocol">IMAP</acronym> download' support one should make sure that the future src/tcp/imap.c should already be prepared to provide full synchronization in future. That means, care should be taken not to implement such download support to basic but keep in mind to develop functions and functionality with synchronization support in mind. Furthermore, this functionality should always be advertised as "<acronym title="Internet Message Access Protocol">IMAP</acronym> download" support and care needs to be taken to distinguish between full <acronym title="Internet Message Access Protocol">IMAP</acronym> support (coming with YAM 3.0) and with such a basic "<acronym title="Internet Message Access Protocol">IMAP</acronym> download" support.
</p>
Resultshttp://yam.ch/ticket/583#changelog