coapp-developers team mailing list archive

[Garrett Serack <garretts@xxxxxxxxxxxxx>]

Ah, she did reply but to me directly:


Yes, that's really the only way to handle notification when you add threading and multiple downloads/installs at a time.  I'm not sure how much feedback we can get from msi's while they install, haven't dug into the documentation yet.

Callbacks sound good to me too.

G


Garrett Serack | Open Source Software Developer | Microsoft Corporation
I don't make the software you use; I make the software you use better on Windows.

From: Philip Allison [mailto:mangobrain@xxxxxxxxxxxxxx]
Sent: Wednesday, June 09, 2010 11:05 AM
To: Garrett Serack
Cc: coapp-developers@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Coapp-developers] Async notification from CoApp Engine (libCoApp)

I'm not Elizabeth, but since there was no reply (at least not that I can see), I'll bite.  Basically, there are only two (sensible) ways to do it: callbacks, or a "get current status" function.  The former is very common, but does require a bit of thread safety awareness in the app's callback implementation, since they obviously won't be called from the same thread the app's main loop is running in.  The "get current status" function means you don't have to care about thread safety in the calling code (unless you want to write a multi-threaded client for other reasons), but obviously the code has to keep polling the library, which can be nasty in and of itself.

Or, you have a hybrid model which is either really fantastic and elegant, or a hideous monstrosity - I can't quite decide: optional callback usage, where the default callback (internal to the library) updates the internal structure used by the "get current status" function in a thread-safe fashion.

Unless anyone has any good reason to do it another way, I vote callbacks.

Regards,
Phil