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

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

Stefan Westerfeld wrote:
> 
>    Hi!
> 
> I'll apply a bit mail-defragmentation (that will be chaos otherwise).

Good idea.

> => 1. component.cc/component.h
> 
> There seem to be two ways to implement both, the artsbuilder API, and a
> nice C++ API.
> 
>  a) Implement the C++ API on top of the artsbuilder API
>  b) Implement the artsbuilder API on top of the C++ API
> 
> Your source looks like the first, my current approach is the second. The
> C++ API for connections etc. is provided by the flowsystem.

The goal of my first version was to introduce some ideas, which we discussed
about already. But it's far from perfect. With the help from your first answer
(and now also this one!), I'm redesigning it to something much clearer.

As for a), and b). As you pointed out, artsbuilder will never be able to write
something like MP3Reader mp3("mysong.mp3"). And it's not at all its goal either.
On the other hand, one would like to be able to program in C++ as easily as
possible, without even understanding how the underlying system works, so would
like to be able to code it directly in the form above.
So, at present, I'm doing:
a) Don't touch the C++ core API.
b) Don't touch the artsbuilder API on top of that C++ API
c) Write nice components using a) and b)

That way, there should be no problem.

> => 2. Using Dispatcher::the()
> 
> You can't use Dispatcher::the() if no dispatcher object exists. That is why
> component.cc/component.h will probably cause a crash. See other sources
> for examples.

I'm aware of that. What I'm writing now won't have this problem, thanks to your
precisions.

> => 3. Object creation and destruction:
> 
> Assume you have a class Foo, and a SpecialFoo derived from that.
> 
>   C++ style                           MCOP style
> ----------------------------------------------------------------
>   Foo *foo = new Foo();            Foo *foo = Foo::_create();
>   Foo *foo = new SpecialFoo();     Foo *foo = Foo::_create("SpecialFoo");
>   delete foo;                      foo->_release();
> 
> The advantage of the second option is that your code doesn't need to know
> about the existence of SpecialFoo's when compiled (you can read that string
> out of a configuration file and such).
> 
> As all objects are derived from "Object", you can always use
> 
>   Object *object = Object::_create("Foo");
> 
> for any MCOP aware implementation.

That is excellent.

> => 4. Could we move the someobject->_node()->start() calls to exec()
>    automatically?
> 
> No, as you can create objects any time. That is, you could create a bunch
> of objects when the user presses a button, when you get a midi event or
> similar. There will be no exec() involved.

That's fine by me, I understand it now. 
someobject->_node()->start() could perhaps be syntaxically symplified. I'll come
back when I have a working example.

> => 5. MCOP Video
> 
> The most sophisticated implementation would be making video frames native
> types, and see that they support zero-copy-streaming even between servers.
> Thus, if you have that
> 
> [ Process A ]   <--- MCOP ---> [ Process B ]
> 
>   video      . . . . . . . . .  X11 displayer
>   decompressor                  for video frames
> 
> these video native types should upon allocation write themselves into a
> shared memory segment, and so not be copied at all between decompressing
> and rendering onto the X11 display.
> 
> Thus we should be able to achive about the same speed than a "conventional"
> one process implementation, as the 25 frames/sec should not involve protocol
> overhead.
> 
> I am looking forward to any implementation I get for this ;) - I'll probably
> look into it again if I am happy with most audio and midi issues, as this
> is what I want to have working first and foremost.

Same here. I thought about it and it's not simple. Problems I see are the 'no
copy at all' for local objects, only one copy over the communication channel for
the remote objects, and synchronisation of video and audio streams.
A problem for later... (but if you're interested, I can post the few ideas I
had).

> => 6. void * pointers for setValue ...
> 
> ... are evil (not network transparent and outside the MCOP typing system).
> Thats not possible. However, there may be the ability to have "any" types
> similar than those CORBA offers.
> 
> Most of the time, you'll write
> 
> object->filename("x.wav");
> 
> or
> 
> frequencyGenerator->frequency(440.0);
> 
> anyway. You only need setValue if you have the idea that you want to
> set a stream to a constant stream of always the same value.
> 
> interface F {   // involves setValue
>         in audio stream frequency;
>         out audio stream pos;
> };
> 
> interface F {   // is possible without that
>         attribute float frequency;
> 
>         out audio stream pos;
> };

Yes, there is always that possibility.
I was confused by the PortDesc arguments, where a boolean is 'hasValue' and
there is no connection stream.
in component.h/cc I created overloaded setValues for floats and strings, but the
'any' would be good. Kind of a void* with type restrictions.


> => 7. Stringified references
> 
> Current API:       AudioProducer_var au = AudioProducer::_fromString(argv[1]);
> your suggestion:   AudioProducer *au = Reference(argv[1]));
> 
> I don't see a too large the advantage. You shouldn't use stringified
> references for most things anyway.

It was just the syntax. And I'm not even happy with it. Let's forget this one...

> 
> => 8. Making an MCOP namespace with simplified connect operations
> 
> Yes. Definitely. ;) I'll do that sometime. Another thing that worries me

OK. I'll see what I can do with the components idea.

> are stereo ports. There are no stereo ports, and thus, you'll often write
> 
> connect(mp3,"outleft",effect,"inleft");
> connect(mp3,"outright",effect,"inright");
> 
> the cleanest thing to have would be
> 
> connect(mp3,effect);
> 
> but something will have to be changed quite a bit for that. Support stereo
> audio ports natively? Support default declaration for more than one port?

I like the last one a lot, but it would not work directly:

interface mp3 {
    default out audio stream left;
    default out audio stream right;
}

interface effect {
    default in audio stream inleft;
    default in audio stream inright;
}

Now the connect(...) function sees that there are 2 defaults in both objects,
all right. But how can it connect right to right and left to left?

Solution, extend the 'default' keyword syntax with this:

interface mp3 {
    out audio stream left;
    out audio stream right;
    default left, right;
}

Now, there is an order. And the following syntax could still be accepted:

interface foo {
    default out audio stream grumble;
    out audio stream beep;
}

> Hope I didn't forget something important.

That covers quite a lot already!

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]