diff --git a/src/include/dummy-player-facade.h b/src/include/dummy-player-facade.h
index af7ba31f7..1d7fb7125 100644
--- a/src/include/dummy-player-facade.h
+++ b/src/include/dummy-player-facade.h
@@ -57,6 +57,11 @@ namespace lumiera {
      * experiences regarding integration of the application layers.
      * Lumiera is not yet able actually to deliver rendered video data.
      * 
+     * In hindsight, this design study highlighted some relevant problems
+     * with our interface layout and the way we create bindings to the
+     * implementation. The moment we attempt to use other abstractions
+     * within an interface (as we do here with the Process interface),
+     * we're running into serious maintenance and library dependency problems. 
      */
     class DummyPlayer
       {
diff --git a/src/proc/play/dummy-player-interface-proxy.hpp b/src/proc/play/dummy-player-interface-proxy.hpp
index 57710c39d..5738a35df 100644
--- a/src/proc/play/dummy-player-interface-proxy.hpp
+++ b/src/proc/play/dummy-player-interface-proxy.hpp
@@ -74,6 +74,7 @@ namespace lumiera {
          *  it directly within the client (=GUI) bypasses the C interface
          *  and thus leaves us only with one level of indirection,
          *  irrespective if using the C or C++ interface.
+         *  @note in hindsight this turned out as a very bad idea
          */
         Process start(LumieraDisplaySlot viewerHandle)
           {
@@ -83,7 +84,7 @@ namespace lumiera {
               throw lumiera::error::State("failed to start DummyPlayer", lumiera_error());
             
             return pP->createHandle();
-          }
+          }            //////////////////TODO here we get library linking problems: createHandle is implemented in liblumieraproc.so and this is necessarily so.