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

List:       kde-multimedia
Subject:    Re: Intro & a couple of MCOP/Arts questions
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2000-05-26 14:34:07
[Download RAW message or body]

   Hi!

On Thu, May 25, 2000 at 01:39:36PM +0100, David Harvey (Hamish) wrote:
> I've just joined the list. I had a brief look at MCOP a few months ago
> but it was still in a quite a rough state. Looking again now I've got
> KDE2 up and running on my home machine (Solaris compiles for work
> continute to give me problems) it seems much more solid.
> 
> My interest in it is this. I am doing a PhD looking at software
> architecture for flood forecasting systems. The architecture that I have
> developed so far (with limited implementation in VisualWorks smalltalk)
> is very similar to the arts architecture. Many of the ideas I had about
> graphical programming for hydrological modelling are similar, I think,
> to the artsbuilder idea (which, I gather, is not yet ported to the MCOP
> based arts framework). Since I came across the same problems with CORBA
> as you did in the development of arts, and since MCOP fits the bill much
> better (most of the system involves independent modelling objects with
> inflows and outflows of data) I thought I would investigate the
> possibilitiy of using MCOP in a field for which it was not specifically
> designed.

I am right now working on porting artsbuilder. However, I have no version
yet which would do something more sensible than crashing ;-)

> Having read back through the recent postings to the list, and round some
> of the arts-project web site, I have some (quick to answer, I hope)
> questions, and a couple of comments.
> 
> 1) In the Linuxmusic interview, Stefan mentioned a chapter in the KDE2
> devel book. It hasn't been released yet. Any ideas when it might be? It
> would be interesting for more than MCOP stuff.

The chapter is still in the review phase. As far as I know it will not be
released before KDE 1.91, however, this only gives the least duration.

> 2) There has been a discussion of the role of SynthModule. This caught
> my eye because I have encountered it in my first attempts to knock
> together some working MCOP objects with streams. I gather that for
> working streams, an object must inherit form SynthModule. I also gather
> that SynthModule is empty - the guts are in StdSynthModule. How tied to
> audio work are these classes (is it just the name which is
> audio-related)? Would you imagine that, if I wanted objects connected by
> async streams which fire packets of data around at intervals (5-15mins
> in real time flood forecasting) that I would make use of StdSynthModule?

Yes, indeed only the name is related to synthesis. The rule is that any
module which is carrying streams has to inherit SynthModule - at least as
long as you use the current flow system (more below). Theoretically you are
free to use or not to use StdSynthModule, practically, I would strongly
recommend.

> 3) I would advise making every attempt to keep MCOP, with complete
> streaming support, cleanly separate from Arts. That way it can be used
> in varied environments, for a multitude of uses. It looks to me like a
> well designed system, and I can imagine it becoming popular anywhere
> that plugin-based or distributed streaming software is required - which
> covers a lot of engineering modelling, simulation and forecasting. This
> might also encourage the use of separate mcop and arts namespaces.

This is not as easy as it may sound. With the current distinction, MCOP
does only what CORBA does, and provides hooks for implementing network
transparent signal flow. The stuff in arts/flow uses these hooks to
implement one way of scheduling signal flow (StdFlowSystem). Basically,
you can reimplement this whole stuff, but clean seperation seems hard to
maintain, if you normally always use StdFlowSystem anyway (because it
contains a lot of work). The plan was to have StdFlowSystem use SynthModule
while other flow systems may want to have different bindings. However, as
things currently stand, as long as there is no other FlowSystem with
significant benefits this could be hardwired, too.

Also, even if you do distributed modelling, you may want to have something
like artsbuilder, which is clearly aRts, then. It should work with your
simulations, too.

What might be an idea to get this cleaner is moving everything out from
arts/flow which is a concrete implementation of a SynthModule, to a new
arts/modules directory.

> 4) Connected with 2 and 3. Just a quick yes/no answer will suffice, so I
> know if it is worth my hunting through the code. Can I build some
> objects which communicate over streams using just the code in the mcop
> directory (and mcopidl, of course) of the arts tree. Or do I need to
> pull in stuff from arts/flow.

You need flow, too.

> 5, and finally) If anyone has some small working examples of MCOP
> objects built from scratch (ie without making heavy use of arts code)
> which talk by streams (the examples directory contains a straight
> message passing example), it would be invaluable. Any stream types would
> be interesting, but particularly async push streams.

Have a look at http://space.twc.de/~stefan/kde/download/asynctest.tar.gz,
this I used to test async streams a bit. However, it may not even compile
or work, as the code is quite old. Other than that there are a few things
int the current sources.

> My C++ coding is still limited, but since I would be using certain
> quite new parts of MCOP, including support for special stream data
> packet types, I might be able to contribute to the development of those
> areas - probably little until I get going, admittedly.

Sounds good. Especially since this stuff needs work. Areas that are really
not nice yet are synchronization and for instance disconnection or error
handling if connected parties die during the process. Also, these things
will be the base for midi streaming, too, so getting this stable would be
nice.

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-         
_______________________________________________
Kde-multimedia mailing list
Kde-multimedia@master.kde.org
http://master.kde.org/mailman/listinfo/kde-multimedia

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