[vlc-devel] Re: Proposals and questions

[Moriarty, Mark F]

Been down this path before, a couple of months ago.

At the end of the day it looked like CORBA would have been overkill for
anything to be used as a VLC control interface by an external
application.  It looked like XML might have hit a "sweet spot" in terms
of bang for the buck, but CORBA was too complex.

This is from a production engineering perspective, real systems
integration.  There's absolutely nothing wrong with Corba, XML, serial,
or anything else, as an intellectual exercise.  If you step back you
realize that at the end you are doing something which IS "proprietary",
since you are implementing a set of highly "tuned" capabilities to allow
things like the instantiation and control of the filters specifically
available within VLC.  Whether it's a 20 byte raw socket rc text string,
or something wrapped up in a KB of whiz-bang CORBA, there is not some
magical, mystical, "good" in a particular interface mechanism.  At the
end, the controlling application has to follow the path: Either
automatically or via user control of my bigger app I want to change
something  -- these are the parameters -- how do I parse this into
something the external app (VLC) can use -- send the stuff out and get
the confirmation   That last part is where CORBA vs RC vs anything else
comes into play -- how much code/test/debug the controlling application
requires to schlep the command out and get the ack back.

I know that there are various toolsets available, but learning curves
with their concomitant additonal cost/schedule impacts generally are
frowned upon in the outside world.  You pick the class of interface
based on the complexity of the subsystem.  You also just plain get more
"stuff" to schlep along, under the different compiler environments.

Again, this is not intended to slight the introduction of a Python
interface, from an intellectual perspective.  A working external
interface of any type for VLC is a valuable learning experience, and may
fit well for a particular niche (an outside app that has already settled
on using Python for a lot of things).  "An interesting target" is an
appropriate description -- if one has the personal interest to learn
more about something, use it, that is good, just that it should not then
be forced on the outside.

-----Original Message-----
From: vlc-devel-bounce at videolan.org
[mailto:vlc-devel-bounce at videolan.org] On Behalf Of Olivier Aubert
Sent: Monday, April 04, 2005 10:36 AM
To: VLC devel
Subject: [vlc-devel] Re: Proposals and questions

Just my .02 euros here (warning, strongly biased content, and I am
mostly repeating myself from a similar thread), related to the rc/rtci
proposal. Instead of implementing a whole new language, why not just use
an existing one and extend it with VLC capabilities ? Python is easy to
extend and embedd, so it looks like an interesting target. Incidentally,
I already implemented a python-vlc module (very different from the basic
one that sits in the vlc tree), which implements on the one hand the
MediaControl.idl API (also used by the CORBA module) and on the other
hand a low-level access to the vlc objects (ability to find objects, to
get/set config options and object variables, etc).

With the adequate environment (the ipython interactive shell), you get
history, completion, etc. It would be easy to extend the current module
with new objects (vlm interpreter, etc). You can find an example
interaction session, as well as the code of the module, at the end of
http://liris.cnrs.fr/advene/download/index_en.html

This proposes a more flexible and powerful approach than the rc/rtci
interface, so that rc/rtci functionality is kept very basic, and more
interactive functionalities are implemented elsewhere. And you get a
real programing language for free (with control structures, variables,
various other modules, etc). Of course, some will say that it is at the
cost of overbloating, but I do not think it is that much compared to the
flexibility it offers.

I am open to any comments or suggestions about it.

Olivier


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

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