This is an approximation what remains todo to get aRts running on MCOP
as it was before on CORBA.

1. API changes

 => SmartWrappers

One of the last big changes before the API is more or less frozen. This is
currently mostly done. Remaining issues are:

- much functionality resides under Object_base, which isn't available if
  you use SmartWrappers now
- writeObject/readObject need review/rewrite
- maybe the two objects SmartWrapper and Object should be merged
- isEqual (and maybe others) would benefit a lot if everything inherited the
  Object wrapper (so that SmartWrapper would be merged), since for conversion
  to Object is currently non-const, which is the reason that (see
  simplesoundserver_impl.cc)

        ByteSoundProducer sender = prod->sender();
        if(bsp._isEqual(sender))                                                

  must be written instead of

        if(bsp._isEqual(prod->sender()))

- check why

     Foo f(SubClass("Bar"))

  doesn't work, currently only

    Foo f = SubClass("Bar");

  the same is true for Reference()

 => Other rough edges

- casting local or remote objects (if you have manufactured them remotely)
  really gives ugly code - maybe provide something like

    StereoEffect effect(Factory(server));
    // which provides typesafe remote manufacturing

  and

    Object o = ...;
	StereoEffect effect(DynamicCast(o));
    // which provides typesafe dynamic casting

- should asynchronous streams start & initialize in the same way synchronous
  do? (with initialize/start/uninitialize)? probably yes.

- provide a way to detect whether clients like artscontrol have died, and
  remove their effects again

- maybe provide a way for clients to identify themselves before using the
  server, so that you can (at a later point of time) configure effects, volume
  and similar dependant on what the client is: no effects for games, but
  effects for the music

2. To get everything up again

- namespaces (mapped to modules in the IDL) - currently MCOP puts every
  interface in the standard namespace
- port visual objects
- do streaming between servers again
- more work on flow graph descriptions (Structure, etc.) -- external interfaces
- more work on dynamic N:M connectivity (SynthBus*)
- port artsbuilder
- port every object
- asynchronous streams (as opposed to synchronous) w/ language binding
- notifications when attributes change
- more work on streaming, for instance:
  - recursive scheduling again (with loops & cycles)
- reading/writing IEEE Floats needs proper documentation, testing on
  different architectures and probably different code for some machines
- more work on audio playing stuff (different sampling rates, different
  hardware, mono, tunable buffer sizes)
- make buffer sizes / samplingrate / depths / ... configurable
- rewrite resampling to work nicely on small blocks (instead of requiring
  the whole sample to be in memory). This in turn leads to
   - allow different sampling rates for artscat (make it work the same also
     regardless whether what samplingrate the server is running on)
   - allow progressive loading for wave files
- write blockwise caching (not requiring whole samples to be held in memory)
- someday implement a clever way how apps that are not written for aRts can
  use /dev/dsp nevertheless, maybe one of:
   - starting artsd only on demand
   - make artsd go to a sleep mode automatically if no clients are connected
   - make artsd go to a sleep mode after a timeout
   - make arts detect automatically when it is silent, and close /dev/dsp
     then (this would for instance also close if clients are connected but
     not playing anything)
   - make an explicit call like "shutdown now" (esdctl off/esdctl on)
- maybe fix crash when playing wav files without libaudiofile installed
- Dispatcher stores a FlowSystem_impl (not a FlowSystem) internally, since
  it wants to have addObject() and removeObject() methods - this leads to
  slightly unlogic accesses from outside
- recording, full duplex

3. To have more fun

- tune the transfer protocol (although MCOP theoretically could do 30000+
  synchronous invocations per second, it can only do 8000+)

  possible tuning operations are
    * rewrite Buffer not to use vector<char> to store data, but malloc'd
	  blocks
    * try to write "zero allocation" invocations, that means, try not to
	  allocate memory on performing an invocation. For instance Buffers
	  could be kept in pools, and be reused for further invocations, without
	  the need to realloc another memory block
    * try to minimize the amount of copies of data, possibly even using
	  something like sharedmem to share data between the sending and
	  receiving buffer

- implement plugins that transfer non-standard datatypes such as midi events,
  video frames, fft packets, oscilloscope views, ... (which was impossible
  with aRts on CORBA)
- make aRts run inside Brahms, KWave or your-favourite-other-app, to do
  signal processing where it is needed (similar to AudioLogic Environment,
  for instance)
- convince other people to use aRts, so that the usefulness of universal
  plugins written for the API increases
- when being crazy, implement gatewaying from MCOP to DCOP, CORBA, XMLRPC
  or whatever else might be useful

Other suggestions:

  => Config dialog:

- instead of using three radio buttons to select latency, use a slider
with three positions (left, middle, and right) with icons beneath them
depicting latency, or labels beneath these points.  More polished looking.

- instead of saying changes must take place when you logout and login,
just restart artsd after the dialog is accepted. (This may also be done
as an additional MCOP interface to change config stuff on the fly, as
restarting will mean that already connected clients (mp3 player) will
crash/hang).

  => Configuration

- make extension dir runtime configurable (not only compiled in)
