[mb-devel] libmusicbrainz3 testing

[Tobias Rundström]

On 23 jul 2006, at 02.29, Lukáš Lalinský wrote:

> Tobias Rundström wrote:
>> You don't need to create threads for doing something Asynchronous.  
>> What
>> I am suggesting is to keep threads OUT OF UI PROGRAMS, because  
>> they have
>> very bad problems with many toolkits.
>>
>> Instead you have a function that reads data from the server in a
>> nonblocking way. Much much better. This way we can also process  
>> multiple
>> requests from one client.
>
> With the current implementation it isn't possible to make the  
> network operations
> work in a non-blocking mode, as all the HTTP code depends on  
> libneon, which
> currently doesn't support it. There seem to be some patches around,  
> but I'd very
> much prefer to depend only on official libneon releases.
>
> I'm personally sure not if this is a good idea anyway, but I agree  
> that it would
> be nice to have it as an option, at least for simpler applications.  
> For any more
> complex applications you probably need to use multiple queries in  
> some specific
> order (e.g. load an release, for each track load relationships, or  
> search for an
> release, get IDs, run a query for each returned ID), I think it'd  
> quickly become
> unusable as you'd probably have to create your own state machine to  
> handle such
> situations. It's probably easier to start a thread and do all  
> queries you need
> in one iteration of the thread's main loop.

In that case I would suggest using libcurl3 instead, it's more or  
less standard (included in debian-base and macosx by default) and  
supports both sync and async operations. Is there a specific reason  
why libneon is the choice?

I have written a couple of UI's in my day and I clearly prefer to use  
async operations since most toolkits don't like to be multithreaded  
(latest qt4 has some nice support for sending signals between  
threads, but I am a creature of habit I guess).

Just my $0.5

-- Tobias