benn/lumiera_
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

set up some steps which might lead to a solution of the typed-query-problem

Browse source
This commit is contained in:
Fischlurch 2009-10-23 20:09:36 +02:00
parent 23c0387298
commit 455ad14ae5
2 changed files with 39 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -23,6 +23,7 @@
#include "lib/test/run.hpp"
//#include "lib/lumitime.hpp"
#include "lib/test/test-helper.hpp"
//#include "proc/mobject/placement-ref.hpp"
//#include "proc/mobject/session/test-scopes.hpp"
//#include "proc/mobject/placement-index.hpp"
@ -41,6 +42,7 @@ namespace mobject {
namespace session {
namespace test {
using lib::test::showSizeof;
//using util::isSameObject;
//using lumiera::Time;
using std::string;
@ -50,11 +52,17 @@ namespace test {
namespace { // a test query resolving facility
struct TypeMatchFilter
class TypeMatchFilter
: public QueryResolver
{
};
QueryResolver&
buildTestQueryResolver ()
{
UNIMPLEMENTED("build a special resolver just for this test and register it.");
}
}
@ -74,13 +82,23 @@ namespace test {
virtual void
run (Arg)
{
Iterator ii = subF2.query<TestSubMO21>();
QueryResolver& resolver = buildTestQueryResolver();
Query<int> firstQuery;
Query<int>::iterator ii = resolver.issue (firstQuery);
explore (ii);
Query<string> secondtQuery;
Query<string>::iterator iii = resolver.issue (secondQuery);
explore (iii);
}
template<typename ELM>
static void
explore (typename Query<ELM>::iterator const& ii)
{
cout << "Query-Results: " << showSizeof(ii) << endl;;
while (ii)
{
subF2.attach(*ii);
cout << string(subF2) << endl;
ii = subF2.query<TestSubMO21>();
}
cout << *ii << endl;
}
};

16
wiki/renderengine.html
View file

@ -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 &quot;condiguration data&quot; (including the actual plugin implementation to be loaded)
</pre>
</div>
<div title="QueryResolver" modifier="Ichthyostega" modified="200910230109" created="200910210300" tags="Rules spec draft img" changecount="6">
<div title="QueryResolver" modifier="Ichthyostega" modified="200910231612" created="200910210300" tags="Rules spec draft img" changecount="7">
<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
@ -3492,7 +3492,7 @@ The situation can be decomposed as follows.[&gt;img[QueryResolver|uml/fig137733.
*# client creates just a goal, which is then translated into a specific query mechanism behind the invocation interface
*# 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
* 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
</pre>
</div>
<div title="RSSReaderPlugin" modifier="Ichthyostega" created="200708081515" tags="systemConfig" changecount="1">
@ -5553,6 +5553,18 @@ Using transitions is a very basic task and thus needs viable support by the GUI.
Because of this experience, ichthyo wants to support a more general case of transitions, which have N output connections, behave similar to their &quot;simple&quot; counterpart, but leave out the mixing step. As a plus, such transitions can be inserted at the source ports of N clips or between any intermediary or final output pipes as well. Any transition processor capable of handling this situation should provide some flag, in order to decide if he can be placed in such a manner. (wichin the builder, encountering a inconsistently placed transition is just an [[building error|BuildingError]])
</pre>
</div>
<div title="TypedQueryProblem" modifier="Ichthyostega" modified="200910231708" created="200910231618" tags="Rules dynamic" changecount="9">
<pre>//the problem of processing specifically typed queries without tying query and QueryResolver.//&lt;br/&gt;This problem can be seen as a instance of the problematic situation encountered with most visitation schemes: we want entities and tools (visitors) to work together, without being forced to commit to a pre-defined table of operations. In the situation at hand here, we want //some entities// &amp;mdash; which we don't know &amp;mdash; to issue //some queries// &amp;mdash; which we don't know either. Obviously, such a problem can be solved only by controlling the scope of this incomplete knowledge, and the sequence in time of building it.
Thus, to re-state the problem more specifically, we want the //definition//&amp;nbsp; of the entities to be completely separate of those concerning the details of the query resolution mechanism, so to be able to design, reason, verify and extend each one without being forced into concern about the details of the respective other side. So, the buildup of the combined structure has to be postponed &amp;mdash; assuring it //has//&amp;nbsp; happened at the point it's operations are required.
!Solution Stages
* in ''static scope'' (while compiling), just a {{{Query&lt;TY&gt;}}} gets mentioned.&lt;br/&gt;As this is the only chance for driving a specifically typed context, we need to prepare a registration mechanism, to allow for //remembering//&amp;nbsp; this context later.
* at the same time, but otherwise independently, compilation needs to drive the generation of possible query resolution mechanisms. As C++ only allows very limited influence on the compilation process, which is always based on a common visibility scope, and on the other hand doesn't allow to re-access the static level after the fact (no language-rooted introspection), we're forced to use an external tool, or to rely on manual specification. As we're building a rather specialised facility, not a general purpose library, the latter seems adequate, if done close to where the actual query resolution mechanism is implemented.
* during ''initialisation'', a complete list of all specifically typed scopes needs to be collected. This might be a flat list, but may well become structured in multiple dimensions later, when using multiple //kinds of query.// It is important to notice that this buildup of a complete list won't happen, unless triggered explicitly, so we need registration into a system lifecycle hook.
* on ''first use'' (which me must ensure to be //after//&amp;nbsp; initialisation) the list-of-typed queries will be hooked into the query resolving facility to build a dispatcher table there.
* the ''actual query'' just picks the respective type-ID for accessing the dispatcher table, making for a total of //two//&amp;nbsp; function-pointer indirections.
</pre>
</div>
<div title="VirtualClip" modifier="Ichthyostega" modified="200808160257" created="200804110321" tags="def" changecount="13">
<pre>A ''~Meta-Clip'' or ''Virtual Clip'' (both are synonymous) denotes a clip which doesn't just pull media streams out of a source media asset, but rather provides the results of rendering a complete sub-network. In all other respects it behaves exactly like a &quot;real&quot; clip, i.e. it has [[source ports|ClipSourcePort]], can have attached effects (thus forming a local render pipe) and can be placed and combined with other clips. Depending on what is wired to the source ports, we get two flavours:
* a __placeholder clip__ has no &quot;embedded&quot; content. Rather, by virtue of placements and wiring requests, the output of some other pipe somewhere in the session will be wired to the clip's source ports. Thus, pulling data from this clip will effectively pull from these source pipes wired to it.