[vlc-devel] Re: Initial rtci interface

Olivier Aubert oaubert at lisi.univ-lyon1.fr
Sun Nov 14 23:42:02 CET 2004


Hello

Some thoughts on this proposal (that I once contemplated but not
implemented, mainly because of the objection raised by Sigmund).

On Sat, 2004-11-13 at 10:25 -0500, Mark Moriarty wrote:
> Good question.  I'm suggesting this because none of the control interfaces
> presently available (that I saw) does what I need. 
> --Computer-communication oriented.
Same needs here: I want my external application to control VLC.

> --Able to be understood by a human being, tested/debugged/used, without
> overly exotic overall structures.  In other words, if the message payload
> becomes too complex, not able to be generated by a human being, we still end
> up with an i-need-something-useable-by-a-person.
While I agree that the success of SMTP, HTTP and other similar protocols
lies in their text-based, human-readable nature, I do not think that it
should be the only Right Way for solving a problem. Computers are here
to lighten the burden of users, for instance parsing and generating
complex code, executing repetitive tasks, ...

>  At times a normal person
> needs to be able to do things, wants to be able to, say, adjust a marquee,
> insert a logo -- don't want to force them to write a complex program to do
> this, if it's something that could/should be doable over a vanilla socket
> console window.
Well, having done this daily for a while, could I suggest that you look
at the interaction examples at
http://liris.cnrs.fr/advene/download/index_en.html
It is console-based. The only difference with your scenario is that I do
not use telnet to connect to VLC, but python in interactive mode
(through the ipython shell, which means that I get completion on method
names, variables, operations, etc).

Your needs could be quite quickly covered. In fact, I plan to implement
logo support (note that there is already SVG support), and the
equivalent of marquee has been there for a while through the subtitle
modules.  I welcome any suggestion and (even better) contribution on the
interface I propose in the MediaControl IDL
(http://liris.cnrs.fr/advene/download/MediaControl.idl). An example
session for your scenario could look like :

import sys, CORBA
orb = CORBA.ORB_init()
mc=orb.string_to_object(sys.argv[1])
mc.playlist_add_item('movie.mpg')
mc.start(0)
mc.logo_display(x=100, y=50, filename='testfile.png')
(x, y) = mc.logo_get_offset()

which could qualify as "usable by a person" and "able to be understood
by a human-being". Especially when you consider that all the
instanciation can be automatically done in a script.
Moreover, from my experience, one of the great interests of CORBA is
that you *have to* clearly define your API in an IDL file, which is an
advantage even when not using the CORBA layer: you get a clear
interface.

> --Reasonably "lean" -- don't want to have as many bytes of object wrapper as
> the control message payload.
"Premature optimization is the root of much programming evil." (C.A.R
Hoare). Why bother in the first place with the message payload, before
getting the work done ? Try to overcome your misconceptions about CORBA
beeing a bloated, heavy software layer (as I once also thought), and see
if it is efficient enough to fit your needs. I use it to have an
external GUI control VLC, and it manages quite well. If it is not
sufficient, try the native python-vlc module, which has exactly the same
API, is slightly more efficient and is easier to build under Windows.


After all this rant about how the CORBA and python approaches may
fulfill your needs, let's be honest: CORBA may sometimes be a pain to
compile (especially on Windows, because of its many dependencies), but
the native python module is more accessible.
Moreover there has been a while since the last CORBA updates because I
had other priorities and  was waiting for a stable development target
before I try to adjust to the floating VLC APIs. If you can lend a hand,
it will be very welcome.


However, if you intend to implement your rtci protocol, you should at
least address the following issues:

* > A single command line may not exceed 240 characters.
This is not a reasonable limit. The GNU coding standards suggest that no
such limit should exist. How do you want to be able to send a large
text ? An inline logo (not just a filename) ? A complex SVG file ?

* You should specify an encoding for returning binary-data (such as
screenshots).

Regards, 

Olivier

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



More information about the vlc-devel mailing list