[vlc-devel] VLC architecture bash

[Rémi Denis-Courmont]

Le samedi 20 septembre 2008 16:02:04 Derk-Jan Hartman, vous avez écrit :
> Each object has a common part and an object specific part.
> The common part holds references to it''s children objects, parent and
> the root. This creates a type of Tree of objects each one responsible
> for its own children.

That really does not address what the use of the tree is - apart from making 
reference counting more crash- or deadlock-prone.

> It also holds variables,

Which sucks, as there is no way to get the list of potential variables and 
values, contrary to a structure or something.

> and flags for various states (dead/dying), 

The only one being actually used is b_die, which is not even thread-safe. 
Besides, it only makes sense per-thread, not per object.

> a name for the object,

Error prone. If the user uses a "special" object name (e.g. "qt4") for its 
object, it can crash the Qt4 embedded window for instance.

> object type id (so we know what type of object 
> specific data is stored after the common part),

Pointless. So you know the object type, so what? Seldom can you use objects of 
different types (decoder and packetizer are the only case I know).

Historically, this has been abused by interfaces to enumerate objects and 
start using the pf_* callbacks (e.g. p_access->pf_control) out of nowhere - 
and boom, that broke thread-safety.

> even a thread reference if needed.

Harmful, as we have learnt during 0.9 development. It creates inconsistent 
behavior, especially w.r.t. to b_die when different instance of a single 
object type may or may not use threads (e.g. access, demuxes...).

It also goes the against the small/simple is beautiful principle. Objects do 
way too many unrelated things. There comes for instance, the mixup 
between "attached means findable, initialized and ready for cross-thread 
interactions", and "attached means inherits configuration variables from 
parents".

And why oh why are module_t derived vlc_object_t: no threads, no variables, no 
plugins there...

> > This allows us to re-use code that we use much throughout the entire 
> > library, without using C++

You don't seriously believe that the horrible vlc_object_t is REQUIRED to have 
re-usable code, do you???

> A variable can inherit it's value from parent objects that have the
> same named variable, or from a configuration option with the same
> name.

And then the parent is destroyed asynchronously, and inheritance breaks.

Yay!

> A variable can have Callbacks that are triggered when it's value 
> is changed, as well as value limits, or lists of allowed named values.

And almost every callback forgets about proper locking and event handling.

Yay!

Oh, and the callback loops too!

> All in all it's very flexible if it works.

Do you really think that mixing all kind of loosely or unrelated features into 
a single all-in-one objects increases flexibility? Come on...

-- 
Rémi Denis-Courmont
http://git.remlab.net/cgi-bin/gitweb.cgi?p=vlc-courmisch.git;a=summary