Tickets :: Comment on [#11983] limit synced mailboxes by user preferences

* Your Email Address
* Spam protection	Enter the letters below: . ..__..___.. ..___ \ /[__] _/ \| \|[__ \/ \| \|./__.\|/\\|\|
Comment	>>> Note that sending the folder via FOLDERSYNC does not necessarily mean >>> it pushes that folder, just that it is available on the device for >>> viewing. On most of the clients I test, the email is lazy loaded into >>> folders other than the INBOX - it only polls the server when you view >>> the folder. Some devices will THEN push to that folder for some time >>> after it is loaded. Other clients have settings that allow you to >>> pick and choose the folders you want pushed vs just available. >> >> It's my observation too that only messages in the INBOX are actually >> pushed to the remote device. But with about 1083 folders (number >> increasing), already processing the list of available folders causes >> a significant slow-down on my remote... >> >>>> On the other hand, my remote device won't let me access >>>> folders not under my INBOX at all, and I definitely don't need all >>>> the sub-folders as available through the web interface. >>> >>> Curious as to what client this is. I've never seen a client limit >>> folders to those only under INBOX. >> >> It's the default client on WebOS 2.x (HP Pre3). >> >>>> As I have been unsuccessful to create a second IMAP user with access >>>> to the same INBOX, but only few of the folders below, I have created >>>> a patch to ActiveSync that allows a user to (currently) select >>>> - only to sync folders below and including the INBOX >>>> - limit the nesting level of the folders synced >>> >>> This of course will only work for IMAP servers that are >>> structured/configured in this way. My server does not place folders >>> under INBOX at all. I have a few hundred mailboxes (of course not all >>> subscribed) and most are at the same level as the INBOX. >> >> Yes, I had anticipated that situation - being able to select which >> folders to sync, similar to selecting which calendars and address >> books to sync, would cover that. > > That would introduce a whole other level of messiness since folders > are more dynamic than address books/calendars. Not that it couldn't > be done. The reason we do this for calendars/address books is because > EAS only supports a single one of each of those. The pref allows the > user to decide which sources to combine into the single data source > that is sent to the client. We don't have to worry about > subscriptions/namespaces etc... with those sources. > > If we do this, I think I'd do it as a INBOX and Special Folders only > or all subscribed folders. > >> That's when I thought that a client-side subscription model, >> implemented on the ActiveSync part (rather than the final mobile >> client) ought to help... and the long time it seems to take to >> process the results of a folder sync, I decided to code a filter >> option for that call. But of course, there may be (and your reply >> says there are) side effects I couldn't foresee. > > I'd need more testing to see exactly how this would affect search and such. > >> Do you see a different, better place to implement such a filter? I'd >> be willing to give this another try. > > You can't use the prefs object inside the library code. This would > have to be implemented inside Horde_Core_ActiveSync_Driver:: probably > in _getMailFolders() or it's own filtering method. > >> BTW: After running this filter on my server/account, processing time >> and data transfer volume have already decreased. But I see many >> instances of supposedly "filtered" folders in the ActiveSync debug >> log, there still is much work left to actually reduce the handling to >> only those folders I actually want to see on the remote :/ > > This might be left over from data not updated in the syncCache of > folder state yet. Once the device requests a new FOLDERSYNC it should > only request data on those folders. In other words, when it receives > a FOLDERSYNC response that indicates that folder FOO is no longer > available, it thinks that folder has been deleted on the server, and > should not issue any more requests for it. > > Update the patch with the above changes and I'll look at adding it in > Horde 5.1.
Attachment
Watch this ticket

Saved Queries