Hi Pali, thanks for your plan. In general, it looks good, even though I have a couple of comments on this.
First of all, the timeframe is missing. I agree that it's great to first decide on *what* to do and only file the detailed timeline later on, so I'm adding this for the sake of completeness. Second, some of the tasks are defined in a rather high-level way. For example, the "create new kpart plugin for kdepim which render trojita GUI into Kontact" is a good first step, but I was hoping for something more integrated, i.e. using Kontact's facilities for notiffying about new mails, etc (assuming there is something like that in Kontact). This will very likely have rather far-reaching consequences for Trojita; proper hooks for actually discovering new messages will have to be provided, facilities for providing really persistent references to messages (nope, QPeristentModelIndex is not enough here) might be needed, etc. What is you opinion about this -- do you consider it something which you'd like to investigate, or something out-of-scope for the GSoC? Comments for the rest are inline.
* add dbus for IPC and single application instance support
I'm not sure whether DBUS is what we want here. In my opinion, the single-instance support is required for acting as the mailto: URL hander in a system, and implementing the single-instance-app on top of DBUS means that Windows/Mac won't get this functionality. I don't care about Windows and Mac that much, but I'd at least like to see some discussion about whether the QtSingeApplication is enough or whether DBUS is better, and why.
* have loaded only one plugin which provides desktop support (addressbook, passwords, ...) and plugin could be choosed in GUI
My first reaction to this is that the plugin should probably be chosen based on what environemnt the application is running in, but perhaps it's wrong (it would certainly be a bit weird if the user suddenly "loses" her addresbook when switching from KDE to something else, for example).
* move addressbook, password, ... code into "internal" trojita plugin (which will be statically linked into trojita as "fallback" plugin)
This is a low-level technical issue appropriate for a discussionabout a particular patch, when it's ready, but why not have it as yet another plugin? Perhaps to make sure that at least some functionality is there even if no plugins could be found? Also please keep in mind that the current address book is tied into the abook implementation rather tightly. This is something to be aware of when designing the interface; perhaps the GUI part of abook management could be offloaded to a given plugin after all?
* create new kpart plugin for kdepim which render trojita GUI into Kontact
Notifications? Providing some kind of a persistent identifier so that Kontact can "attach" mails to e.g. events in a calendar? Perhaps that's impossible without pretending to be an akonadi backend, in which case it's out of a table, but still worth a discusssion. I agree with Kevin's mail later in this thread where he is strongly in favor of async interfaces -- these are harder to write, but provide huge benefits. So, the proposal looks good, and I'm interested in your answers and, when that phase is done, in a timetable of when you think you'll be able to have the individual pieces finished. Sorry for not responding earlier, got busy at work, fell ill and received a shine new camera :) -- that's too many distractions in a single week. I hope this will get better on my side now. Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
