[vlc-devel] Questions about VLC architecture

[Derk-Jan Hartman]

On 20 sep 2008, at 14:26, Justus-bulk at Piater.name wrote:
> Hi,
>
> There are two fundamental design ideas in VLC whose rationale I don't
> understand, vlc_object_t (misc/objects.c) and the named variables
> (misc/variables.c). I did not find the answers in the developer's
> wiki:
>
> - The objects look like they implement a sort-of poor man's
>  inheritance, but without the notational convenience, conciseness and
>  type safety of an object-oriented language. I guess this is mostly a
>  legacy issue?
>
>  Secondly, it looks like all kinds of objects are stored inside a
>  single tree (per libvlc instance). Why's this? What does this afford
>  over and above a conventional design where each subsystem takes care
>  of its own data structures?

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.
It also holds variables, and flags for various states (dead/dying), a  
name for the object, objecttype id(so we know what type of object  
specific data is stored after the common part), even a thread  
reference if needed.

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

> - Similarly, why does VLC need a central repository of named
>  variables? Why cannot each subsystem maintain its own variables?  To
>  me as a newcomer to VLC code, this variable tree looks unwieldy,
>  error prone, and inefficient. Again, what does it afford over and
>  above a conventional design where each subsystem takes care of its
>  own data structures? And why are dynamically-named variables needed
>  at all?

There is no central repository. All variables are connected to an  
object.
What is important to understand with variables is that a variable is  
uniquely identified by it's name AND a specific object, for the  
duration of said object.

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. 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.  
(To match a value for a device with a human readable string for  
instance). There are 9 classes of variables (mutex,time,float,int,bool  
etc).

All in all it's very flexible if it works. (variable inheritance is a  
tad damaged atm). You can define a variable in a module for instance,  
that immediately inherits its default or non-default setting from the  
preferences. Add a list of descriptions for the string, mark it as a  
command. Then in the interface, you find this variable and use it to  
build a menu entry for instance. Whenever someone changes the option,  
the variable is set and triggers it's callbacks.

It is however arguably used a bit too much and too careless atm.

DJ

> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> http://mailman.videolan.org/listinfo/vlc-devel