[vlc-devel] commit: stats-change variable for statistics/ removing stats timer from qt4 interface (Ilkka Ollakka )

[Rémi Denis-Courmont]

On Mon, 13 Oct 2008 09:42:18 +0200, Laurent Aimar <fenrir at via.ecp.fr>
wrote:
>> Note, that was done on purpose to:
>> - centralize possible events, and be quickly able to find every
>> possible event in libvlc
>> - simplicity
>> But for the internal libvlccore API this is not what we want.

I don't know for simplicity.
Centralization sounds like a mis-feature to me.

>> However fixing this shouldn't be too complicated, and we have plenty
>> way of fixing that...
> Current vlc event is not really usable and should be redisigned before
> using it elsewhere.
> 
>> Yet, variables shouldn't be used in that case and we should move to
>> event.
>  Why ? (I am not against changing it)s
>  Because designing a new API without having in mind what are the
> downsides/issues
> of the old one is the best way to do the same errors.
> 
> The "variable" event way has:
> - easy (un)registration.

Yeah, although the locking scheme is weird and slightly broken.

> - easy without ABI break extension

Bof. Adding APIs does not break the ABI in anyway.
Changing an API or removing it will explicitly break the source code.

Changing the semantics (or removing) a variable will break silently. Very
bad.

> - automatic way to get the value associated to an event (in the event
> callback but also outside it which is really important,
> and without duplicated code).

An event handler that would not pass the relevant data... I would not dare
to call that an event handler if it existed :)

> - uniformized value transport.
> - transport of the emiter object.
> 
> The downsides I see:
> - hard(impossible) to transport coherent multitple values for a complex
> event.
> - event callback in the emiter thread.

I consider this a feature. With that, you can re-act synchronously
_if_needed_. If you want/need asynchronous handling, you can still do that,
e.g. with a condition var and a lock. But it is true that synchronous event
handlers are more prone to shooting one's own foot. Also, in many cases,
synchronous handling is impossible, especially if it involves User
Interaction (--> all the audio/video menus).

> - not easy to find which events are available (but that's a documentation
> issue)

No type safety. Compare to the work-in-progress msg subscription stuff from
yesterday.

-- 
Rémi Denis-Courmont