[vlc-devel] Proposals and questions

[Clément Stenac]

Hello,

Here are some proposals and questions for 0.8.3

I: Per-instance variables
-------------------------

Except for stream output, we only use global configuration variables,
like logo-file for example. This is not optimal when you can have
several instances of the object that uses this variable.

Typical example is for filters, if you want to have two logos, you
simply can't.

The proposal is to be able to add instance configuration values to
module types of variables, like sout does.

Examples : 

--filter logo{file=one.png},logo{file=two.png} 
--sub-filter marq{marquee="text1"},time,marq{marquee="text2"}

For this, we would need to unify all modules chains/lists parsing
functions and add variable setting capabilities to them.

This fits for initial setting of variables, but does not solve
on-the-fly changing.

There are currently several strategies :

* either register callbacks in vlc or libvlc objects and set these
  variables (marquee, equalizer, ...) : this is easy and fast, but it
  can't work at all for instance-specific values.

* register in the object and set the variable in the first object found
  (used by vout, ...) : this works poorly too (if you have two vouts,
  for example)

For this, I don't have a great proposal, because none is perfect, and
all are quite user-unfriendly. This is related to the RC interface, so I
put proposals in the next section.

II: RC/RTCI/Telnet interfaces
-----------------------------

Quite a mess here.

This proposal is not new here : merge these interfaces.

We should have only one interface, that would have the following
features:
- authentication
- multi-connexion
- optionally, advanced readline-type features : history,
  auto-completion, yanking, ... (some example code can be found in
  quagga, for example). But this is quite boring to make, as, if I
  understand correctly, libreadline can't read over a socket, only with
  stdin/stdout.
  
I propose that commands are organized in a tree in which you can enter.

play
stop
pause
....
set an OTF variable
get an OTF variable
vlm
  setup ...
  control ...

Each command would have an associated callback function. Lines are
tokenized and passed to these callbacks.

A series of "prefix" indicate where in the tree you are.

Example: 

Commands are "vlm" (VLMCallback), "play" (PlaybackCallback), "stop"
(PlaybackCallback) and "exit" (ExitCallback).

The goal is that you can use "vlm setup foo bar" or "vlm" to "enter vlm
mode" and then "setup foo bar". To get out of vlm mode, you have to type
exit (IOS-like syntax).

So, if VLMCallback is called with only one token in the list, it will
add the "vlm" prefix to the prefix stack. "exit" pops a prefix from the
stack, and performs a logout if the stack is empty.

Each command also features a right level. Users could be defined
(login + hashed pwd + access level) in a configuration file.

Another thing that would be appreciable is an option for
machine-readable or human-readable output (for easy interaction with
other programs, though things like XML-RPC or SOAP might be better for
this).

So, about OTF variables : 

* Either we use the module id... not very intuitive ("set 117 logo-file
  ...")

* Either a number (1,2,3). We find all the modules of the right type
  (to find the type, we need to build a list of OTF-variables), and set
  the var in the 1st one, or 2nd one, .... If no number is specified,
  set it in all modules. 
  That might be a bit slow, though, but you generally don't set otf
  variables thousands of times per second).

* A more flexible solution would be to be able to give a name to the
  module (ex logo{file=blabla.png,name=foo}) and you would "set foo
  logo-type blabla2.png".

In all cases, it would of course remain possible to set the var in all
instances at once. We would need new helper functions to unify all this
(at the moment, there is some code for this in several interfaces).

Any remarks, suggestions, ... ?

-- 
Zorglub
Clément Stenac

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html