[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Easy MCOP! The Component extension proposal.
From:       Nicolas Brodu <nicolas.brodu () free ! fr>
Date:       2000-03-05 23:09:09
[Download RAW message or body]

Hi there.

Though very new to MCOP (about one week...), I've dug in the code and started
implementing things of my own. You'll find below some thoughts and ideas,
halfway done already, but I ask for some feedback/comments/help/flames before 
continuing.
This mail is quite long, sort of compensate for the traffic on this list...

Here we go. First the motivation. If you look at the testflow examples, you'll
notice that each module definition is about 15 lines, and contains 95% of
administrative code (i.e. code just there to set up things). My goal is to keep
all the MCOP features, but remove all those administrative tasks and ultimately
be able to write something like this (concepts from Qt and VTK):

	MP3Reader mp3("mysong.mp3");          // object created directly
	AudioProducer au(Reference(argv[1])); // use MCOP reference/string
	Mixer mix(2);                         // variable number of ports
	mix.inputLevel(1,.80);                // standard method call
	mix.inputLevel(2,.50);
	AudioPlayer *play = new AudioPlayer;  // dynamic allocation works also
	connect(&mp3,&mix,"input1");          // connect the streams. No need 
	connect(&au,&mix,"input2");           // to tell the port name when a 
	connect(&mix,play);                   // default port is defined
	exec();                               // run this

No more administrative code, and it'is now clear what it does (I don't know
about you, but filling all those Port/PortDesc/ModuleDesc/StructureDesc with
stacks of arguments everywhere is not that intuitive to me).

To do this, I've defined a new keywork "component" for the idl. It's exactly the
same as an interface for now, except that this allow the generation of the
necessary code automatically (halfway implemented). In the future, some more
keywords (like default) could be used (to specify a default port to connect to
in a given direction in this example) with the components.

Line by line walk through (and state of art of what I implemented at present):

The first feature above, constructors (as in MP3Reader mp3("mysong.mp3")) could
also use an idl keyword. Easy too implement though I code them directly for now.
Creating from a reference: I coded it, don't know if it works.
Variable number of ports: Should be feasible, but I didn't think about it more
than that yet.
Dynamic allocation: No problem, I solved the reference counting stuff in both
automatic and dynamic allocation.
Connecting: Should work, but could not test it. I also coded a setValue function
for those input ports that don't connect but have a value instead.
Executing: Coded, but doesn't work. Argl. I balked off there. Stefan, do we
really need to derive from SynthModule to be able to use the port connecting
system? I've spent hours looking in the code already and know better how it
works now, but I've encountered this problem an hour ago and decided to talk
about all this before going further on (It might save me some time).

Technical question:
This factory stuff, how is it supposed to work exactly? I mean, if you don't
create one with the REGISTER_IMPLEMENTATION macro then you cannot use your
implementation (warned in object.cc, IIRC), and if you cannot use the macro if
you don't have a constructor without arguments. But then, why does the system
want to create a new instance using the factory if you already have one. Is
there a problem with the reference counting?
Well, assuming this has no effect, I declared a constructor() and registered.
Problem, it now wants a SynthModule. Hence my question, do we need a SynthModule
to use the port connection system?
Last thing, I noticed that the stream can only handle floats (audio_data) or
strings (string_data). Is there a way to really have byte stream?

I know that there is already a lot to do on MCOP, and I'm ready to help there.
But I also think that having an API as the one sketched above would be
tremendously better than the current system (hence this proposition now, while
MCOP can still be modified to some extent).

For information, I'm using the 20000229 snapshot and didn't spend time to merge
in the network transparency. I'm using two components, FileReader and FileWriter
that can produce and consume a byte stream as a basic example.

Anybody see a major flaw/impossibility in this?

Cheers,
Nicolas
-- 
A shortcut is the longest distance between two points. (unknown author)

[prev in list] [next in list] [prev in thread] [next in thread]