[Adium-devl] Importer API

Peter Hosey boredzo at gmail.com
Wed Apr 11 05:47:51 UTC 2007


On Apr 10, 2007, at 17:23:13, Graham Booker wrote:
> The calling thread does *not* wait!

Then there's no reason for the -beginImportingAccounts method to  
return anything, except maybe a token that can be used to cancel the  
import. (Allowing Cancel would probably be a good idea.)

> The calling thread is the process's run loop,

Run loops are per-thread, not per-process. Any thread can have a run  
loop if it wants one.

Perhaps you meant:

	The calling thread is the main thread,

I'll continue under that assumption.

> Essentially, the thread, after it has completed, does a  
> performSelectorOnMainThread and then exits.

So it would be performing some sort of delegate callback message?

> … importing logs takes too long to block this thread.  I was  
> simply stating that the user cannot continue to the next pane in  
> the import "wizard" until this has completed.
>
>>
> The run loop is free to process other things, such as IMs, logins,  
> etc...  Only this window is blocked from continuing further.

Seems like we don't need the import wizard for that. We can order out  
the wizard and just show a regular progress panel, rather like the  
one Sparkle uses.

>> And once you make one of them asynchronous, we may as well keep  
>> them consistent and make the rest of them asynchronous.
>
> Actually, the others should not be asynchronous.  Granted, the  
> situation is rather rare, but the user could possibly mess with the  
> accounts while the importer is importing other accounts. …  
> Importing logs doesn't mess with Adium's internal data structure,  
> and it takes a while, making it a perfect candidate for a thread.   
> Importing accounts and status messages does not take long, but  
> screws with Adium's internal data structure, making it a lousy  
> candidate for a thread.

Agreed.

> Besides, in terms of the API, it changes nothing, except that the  
> import log function must do actions which are thread safe, which it  
> is very unlikely that it wouldn't in the first place.

Right. That's really not an API issue at all; it's an implementation  
detail.
___________________________________
\ Peter Hosey / boredzo at adiumx.com
PGP public key ID: C6550423 (since 2007-01-01)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20070410/745f1df3/attachment.sig>


More information about the devel mailing list