Re: Connecting and account management

[Philip Van Hoof <spam pvanhoof be>]

This patch is now in a branch:

https://svn.tinymail.org/svn/tinymail/devel/pvanhoof/sessionwork/
http://www.tinymail.org/trac/tinymail/changeset/2509


On Fri, 2007-07-27 at 03:42 +0200, Philip Van Hoof wrote:
> (Yes I know it's a lot text, it's pretty important I think)
> 
> Today we had a discussion on the #tinymail IRC channel about connecting
> and account management. We concluded that we needed a rewrite and that
> these are the requirements and the difficulties (a bit mixed together):
> 
> Please read these carefully, as they'll make it more easy for you to
> understand the "full" scale of the problem domain.
> 
>   o. The TnyDevice can issue a connection_changed signal, which
>      means that the accounts (all of them) must be set to offline or
>      online depending on the status of the device's instance (not the
>      actual device, but what the device's instance says. As it's up to
>      the app developer to decide what really is and what really isn't
>      "being online").
> 
>   o. Accounts can be set either online or offline
> 
>   o. Setting an account online can mean that in that thread, the
>      alert_func, get_pass_func and forget_pass_func will happen. It
>      would be a lot less difficult for the application developer to see
>      those three functions happen in the GMainLoop in stead.
> 
>   o. Those are to be implemented by the app developer, which means that
>      he can use ui code. This has a bunch of implications about
>      threading that we really like to avoid as much as possible.
> 
>   o. Proposed is to bring those to the GMainLoop't thread (gtk_main()'s
>      thread)
> 
>   o. While connection, accounts should not attempt to do operations.
>      Such operations should either be queued in case of _async ones, in
>      the TnyCamelQueue, or an error should be set
> 
>   o. The TnyCamelSendQueue and TnyCamelTransportAccount can make an
>      early connection attempt for in case emails are in the outbox and
>      the app developer decides to activate the sendqueue at
>      initialisation of the application
> 
>   o. A connection on any account type can cause an SSL warning that MUST
>      be answered by the user with yes or no. Right now this question
>      happens in a thread.
> 
>   o. a connection on any account type can cause a password dialog that
>      MUST be answered by the user. Right now this happens in a thread.
> 
>   o. The app developer must have the possibility to set a different
>      username during the get_pass_func routine. This is an exception
>      that must indeed be supported by Tinymail.
> 
>   o. It must be possible to add an account. While this account is being
>      added, its initial connection status must be set to the device's
>      current connection status. This means that if the device is online
>      and an account is registered, that the account must go online
> 
> 
> The attached patch attacks a few of these problems already. It also
> deals with things that we'll need in future. For example letting the
> connection itself happen on the individual queues of each store account
> instance, in stead of in random threads.
> 
> It also makes connecting happen reliably yet in parallel with other
> accounts. This improves the amount of time needed "to go online".
> 
> This means that we can't detect when ALL accounts are connected. We can
> only detect when ONE account's connection state has changed.
> 
> This is why there are significant adaptations to the folder store tree
> model too: the changes cope with connection state changes. The changes
> assume that if a store account goes online, it's possible that new
> folders will be available. Especially the first time the account is
> used, will this pull-in not yet seen folders.
> 
> This means that it's not needed to have a accounts-reloaded handler
> anymore. It is, however, now needed to add the created accounts manually
> to the TnyGtkFolderStoreTreeModel instance, as soon as you created it.
> 
> There's also no connecting-finished signal anymore. That's quite simply
> because there's no more way to know when ALL accounts are done
> connecting: their request to get connected is put on their queue, and
> then it's not in the hands of the session anymore. 
> 
> The accounts will of course signal when their connection-status got
> changed in the connection-status-changed signal. This is a very clean
> and good way to know about connectivity changes. The TnyGtkFolderStore-
> TreeModel uses the same signal, by the way, to know when exactly to
> start pulling new folders locally.
> 
> 
> This indeed implies, and you read that correctly, a significant change
> in for example Modest. However, if we ever want to have control over
> these account initialisation and connection problems, hangs and lockups,
> we'll need to do things differently. Yes we do.
> 
> The account management of Modest has its problems too, so it's not a bad
> idea to review all this.
> 
> I'm not yet committing this into Tinymail as I'd like to see a patch for
> Modest that gets Modest working with this before I commit. I will take a
> look tomorrow, and hope that others will do the same.
> 
> I have extensively documented the code. Please read the in-code inline
> comments. I will most likely make an overview on a wiki page on the
> Tinymail trac too. It should be really clear and easy what will happen
> now, as there's really .. really .. REALLY a lot inline comments and
> documentation explaining line by line what is happening.
> 
> I'm planning and expecting to commit this next week on Monday. I hope
> that some Modest people can start taking a look more early.
> 
> 
> Note that the reason and idea is to improve stability, indeed. Although
> it's a big change, I think bigger changes are needed in both Modest and
> Tinymail to indeed improve the stability situation. That is precisely
> what this major change is all about, yes.
> 
> 
> 
> * Hoping that a lot people will review this larger patch *
> 
> 
> 
> _______________________________________________
> tinymail-devel-list mailing list
> tinymail-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/tinymail-devel-list
-- 
Philip Van Hoof, software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://www.pvanhoof.be/blog