13
edits
User:Jminta/Steel: Difference between revisions
no edit summary
Srobertson (talk | contribs) No edit summary |
Srobertson (talk | contribs) No edit summary |
||
| Line 337: | Line 337: | ||
* srobertson: In response to your <code>getFolders()</code> comment. I'd encourage you to make the programming model as async as possible. If we avoid synchronous methods we can keep the UI responsive and not have to worry about whether this folder is local or remote on a mail server. | * srobertson: In response to your <code>getFolders()</code> comment. I'd encourage you to make the programming model as async as possible. If we avoid synchronous methods we can keep the UI responsive and not have to worry about whether this folder is local or remote on a mail server. | ||
** jminta's response: I agree that blocking the UI for a long time would be a bad idea, but at the same time, async requests are inherently more complex. Especially for get() methods, I think we win if we can abstract away the async part and expose a synchronous method to these consumers. | ** jminta's response: I agree that blocking the UI for a long time would be a bad idea, but at the same time, async requests are inherently more complex. Especially for get() methods, I think we win if we can abstract away the async part and expose a synchronous method to these consumers. | ||
*** It's been my experience that you need to develop the knack for async. When you have toolkits that provide both async and sync everoyne will take the path of least resistane and go for the sync methods first because they are so easy to get your head around. Then they get disappointed because performance is so horrendous. I propose that you worry about async for version .1 and introduce sync methods in the future if there becomes a big demand for them. Just my two cents. | |||
=== steelIFolder === | === steelIFolder === | ||