WIP: reworked the design further

tests/components/proc/mobject/session/query-resolver-test.cpp

@@ -84,17 +84,15 @@ namespace test    {
         {
           QueryResolver& resolver = buildTestQueryResolver();
           Query<int> firstQuery;
-          resolver.issue (firstQuery);
-          explore (firstQuery);
+          explore (firstQuery (resolver));
           
           Query<string> secondQuery;
-          resolver.issue (secondQuery);
-          explore (secondQuery);
+          explore (secondQuery(resolver));
         }
       
       template<typename ELM>
       static void
-      explore (typename Query<ELM>::iterator const& ii)
+      explore (typename Query<ELM>::iterator ii)
         {
           cout << "Query-Results: " << showSizeof(ii) << endl;;
           while (ii)

uml/lumiera/131077

@@ -1,6 +1,6 @@
 format 58
 "ConfigQuery" // CommonLib::ConfigQuery
-  revision 13
+  revision 14
   modified_by 5 "hiv"
   // class settings
   //class diagram settings
@@ -651,6 +651,23 @@ ${inlines}
       idl_decl ""
       explicit_switch_type ""
       
+      classrelation 187397 // pos_ (<unidirectional association>)
+	relation 177029 --->
+	  a role_name "pos_" protected
+	    cpp default "    ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value};
+"
+	    classrelation_ref 187397 // pos_ (<unidirectional association>)
+	  b parent class_ref 156933 // Result
+      end
+
+      classrelation 187525 // source_ (<unidirectional association>)
+	relation 177157 --->
+	  a role_name "source_" protected
+	    cpp default "    ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value};
+"
+	    classrelation_ref 187525 // source_ (<unidirectional association>)
+	  b parent class_ref 158085 // SolutionResultSet
+      end
     end
 
     class 155525 "ResolvingFacility"
@@ -681,17 +698,15 @@ ${inlines}
 	    cpp default "    ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value};
 "
 	    classrelation_ref 186117 // <unidirectional association>
-	  b parent class_ref 158085 // Solution
+	  b parent class_ref 158085 // SolutionResultSet
       end
     end
 
-    class 158085 "Solution"
+    class 158085 "SolutionResultSet"
       visibility package 
-      nactuals 2
+      nactuals 1
       actual class class_ref 155141 // Query
         rank 0 explicit_value ""
-      actual class class_ref 155269 // Cursor
-        rank 0 explicit_value ""
       cpp_decl "${comment}${template}class ${name}${inherit}
   {
 ${members}  };
@@ -703,12 +718,12 @@ ${inlines}
       idl_decl ""
       explicit_switch_type ""
       
-      classrelation 185989 // <generalisation>
-	relation 175621 ---|>
+      classrelation 187269 // <generalisation>
+	relation 176901 ---|>
 	  a public
 	    cpp default "${type}"
-	    classrelation_ref 185989 // <generalisation>
-	  b parent class_ref 155269 // Cursor
+	    classrelation_ref 187269 // <generalisation>
+	  b parent class_ref 155141 // Query
       end
     end
   end

uml/lumiera/137733.diagram

@@ -10,7 +10,7 @@ classcanvas 128133 class_ref 155141 // Query
 end
 classcanvas 128517 class_ref 155397 // IterAdapter
   draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_members_multiplicity default show_members_initialization default member_max_width 0 show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default show_stereotype_properties default
-  xyz 46 222 2000
+  xyz 24 222 2000
 end
 classcanvas 128645 class_ref 155525 // ResolvingFacility
   draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_members_multiplicity default show_members_initialization default member_max_width 0 show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default show_stereotype_properties default
@@ -28,7 +28,7 @@ classcanvas 131205 class_ref 155269 // Cursor
   draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_members_multiplicity default show_members_initialization default member_max_width 0 show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default show_stereotype_properties default
   xyz 246 339 2005
 end
-classcanvas 133509 class_ref 158085 // Solution
+classcanvas 133509 class_ref 158085 // SolutionResultSet
   draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_members_multiplicity default show_members_initialization default member_max_width 0 show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default show_stereotype_properties default
   xyz 355 444 2000
 end
@@ -56,24 +56,38 @@ relationcanvas 132357 relation_ref 169733 // <realization>
 end
 relationcanvas 133125 relation_ref 174469 // <unidirectional association>
   geometry VHr
-  from ref 128133 z 1999 stereotype "<<type-def>>" xyz 95 319 3000 to point 77 317
+  from ref 128133 z 1999 stereotype "<<type-def>>" xyz 64 319 3000 to point 55 317
   line 133381 z 1999 to ref 128517
   no_role_a no_role_b
   no_multiplicity_a no_multiplicity_b
 end
-relationcanvas 133637 relation_ref 175621 // <generalisation>
-  geometry VHV unfixed
-  from ref 133509 z 1999 to point 379 411
-  line 133765 z 1999 to point 266 411
-  line 133893 z 1999 to ref 131205
-  no_role_a no_role_b
-  no_multiplicity_a no_multiplicity_b
-end
 relationcanvas 134021 relation_ref 175749 // <unidirectional association>
   decenter_end 830
-  from ref 128645 z 1999 stereotype "<<produce>>" xyz 428 406 3000 to ref 133509
+  from ref 128645 z 1999 stereotype "<<produce>>" xyz 450 406 3000 to ref 133509
   no_role_a no_role_b
   no_multiplicity_a no_multiplicity_b
 end
+relationcanvas 134149 relation_ref 176901 // <generalisation>
+  geometry VHV unfixed
+  from ref 133509 z 1999 to point 402 422
+  line 134277 z 1999 to point 195 422
+  line 134405 z 1999 to ref 128133
+  no_role_a no_role_b
+  no_multiplicity_a no_multiplicity_b
+end
+relationcanvas 134789 relation_ref 177029 // <unidirectional association>
+  from ref 128517 z 1999 to point 89 239
+  line 135301 z 1999 to ref 131077
+  role_a_pos 101 240 3000 no_role_b
+  no_multiplicity_a no_multiplicity_b
+end
+relationcanvas 134917 relation_ref 177157 // <unidirectional association>
+  from ref 128517 z 1999 to point 89 251
+  line 135557 z 1999 to point 144 251
+  line 135173 z 1999 to point 195 461
+  line 135045 z 1999 to ref 133509
+  role_a_pos 101 253 3000 no_role_b
+  no_multiplicity_a no_multiplicity_b
+end
 preferred_whz 629 529 1
 end

uml/lumiera/5.session

@@ -4,10 +4,8 @@ diagrams
     575 622 100 4 0 0
   classdiagram_ref 136325 // Focus of Query
     582 515 100 4 0 0
-  classdiagram_ref 136581 // MObjectRef
-    651 533 100 4 0 38
   active  classdiagram_ref 137733 // Query Interface
-    629 529 100 4 0 0
+    629 542 100 4 0 0
 end
 show_stereotypes
 selected 

uml/lumiera/lumiera.prj

@@ -1,6 +1,6 @@
 format 58
 "lumiera"
-  revision 56
+  revision 57
   modified_by 5 "hiv"
   cpp_root_dir "../../src/"
 

wiki/renderengine.html

@@ -3476,7 +3476,7 @@ Then, running the goal {{{:-resolve(T, stream(T,mpeg)).}}} would search a Track
 In the design of the Lumiera Proc Layer done thus far, we provide //no possibility to introduce a new object kind// into the system via plugin interface. The system uses a fixed collection of classes intended to cover all needs (Clip, Effect, Track, Pipe, Label, Automation, ~Macro-Clips). Thus, plugins will only be able to provide new parametrisations of existing classes. This should not be any real limitation, because the whole system is designed to achieve most of its functionality by freely combining rather basic object kinds. As a plus, it plays nicely with any plain-C based plugin interface. For example, we will have C++ adapter classes for the most common sorts of effect plugin (pull system and synchronous frame-by-frame push with buffering) with a thin C adaptation layer for the specific external plugin systems used. Everything beyond this point can be considered "condiguration data" (including the actual plugin implementation to be loaded)
 </pre>
 </div>
-<div title="QueryResolver" modifier="Ichthyostega" modified="200910231612" created="200910210300" tags="Rules spec draft img" changecount="7">
+<div title="QueryResolver" modifier="Ichthyostega" modified="200910241336" created="200910210300" tags="Rules spec draft img" changecount="10">
 <pre>Within the Lumiera Proc-Layer, there is a general preference for issuing [[queries|Query]] over hard wired configuration (or even mere table based configuration). This leads to the demand of exposing a //possibility to issue queries// &amp;mdash; without actually disclosing much details of the facility implementing this service. For example, for shaping the general session interface (in 10/09), we need a means of exposing a hook to discover HighLevelModel contents, without disclosing how the model is actually organised internally (namely by using an PlacementIndex).
 
 !Analysis of the problem
@@ -3493,6 +3493,11 @@ The situation can be decomposed as follows.[&gt;img[QueryResolver|uml/fig137733.
 *# client issues a query and expect it just to be handled by //some//&amp;nbsp; suitable resolver
 * thus it's difficult to determine, //what// part of the issued query needs automatic management. More specifically, is it possible for the client to dispose the query after issuing it, but keeping and exploring the iterator obtained as result of the query?
 * and then there is the notorious problem of re-gaining the specifically typed context //behind//&amp;nbsp; the invocation interface. Especially, the facility processing the query needs to know both the expected result type and details about the concrete query and its parametrisation. &amp;rarr; TypedQueryProblem
+
+!!!Decisions
+* while, in the use case currently at hand, the query instance is created by the client on the stack, the possibility of managing the queries internally is deliberately kept open. Because otherwise, we had to commit to a specific way of obtaining results, for example by assuming always to use an embedded STL iterator.
+* we endorse that uttermost performance is less important than clean separation an extensibility. Thus we accept accessing the current position pointer through reference and we package a ref-counting mechanism together with this current position (&quot;Cursor&quot;)
+* the result set is not tied to the query &amp;mdash; at least not by design. The query can be discarded while further exploring the result set.
 </pre>
 </div>
 <div title="RSSReaderPlugin" modifier="Ichthyostega" created="200708081515" tags="systemConfig" changecount="1">