planning TypedID (registration service)

wiki/renderengine.html

@@ -5979,8 +5979,8 @@ 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 "simple" 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="TypedID" modifier="Ichthyostega" modified="201003210004" created="201003200157" tags="Model Rules design draft" changecount="16">
-<pre>//3/10 currently investigating necessity//
+<div title="TypedID" modifier="Ichthyostega" modified="201004031509" created="201003200157" tags="Model Rules design draft" changecount="29">
+<pre>//drafted service as of 4/10 &amp;mdash; &amp;rarr;[[implementation plans|TypedLookup]]//
 An registration service to associate object identities, symbolic identifiers and types.
 
 !Motivation
@@ -6005,14 +6005,59 @@ A registration service backed by an index table can be used to //translate//&amp
 
 !!!{{red{WIP}}}Analysis and discussion
 Still some contradictions &amp;mdash; and rather seems helpful, not so much necessary.
-We //already have an registration service,// both for Assets (AssetManager) and for Placements (PlacementIndex). These facilities maintain not only a raw ID &amp;harr; object association, but also structuring informations, albeit bound to more specific circumstances (the system of placement scopes, and the asset category). Thus, still lacking is a ''system of sub index tables''.
+We //already have an registration service,// both for Assets (AssetManager) and for Placements (PlacementIndex). These facilities maintain not only a raw ID &amp;harr; object association, but also structuring informations, albeit bound to more specific circumstances (the system of placement scopes, and the asset category). The lookup uniqueID &amp;rArr; object could be implemented by sequentially querying this small number of central registration facilities. Thus, still lacking is a ''system of sub index tables''.
 
 As mentioned above, an ID &amp;harr; type association plays a crucial role when it comes to implementing any kind of rules based configuration. It would allow to bridge from our session objects to rules and resolution working entirely symbolic. (&amp;rarr; [[more|ConfigQueryIntegration]]). But, as of 3/2010 this is a //planned feature and not required to get the initial pipeline working.// Thus, according to the YAGNI principle, we shouldn't engage into any implementation details right now and just create the extension points.
+
+The immediate need prompting to start development on this facility, is how to get sub-selections from the objects in the session and for certain kinds of asset &amp;mdash; especially how to deal with retrieving the referred track for the &amp;rarr; [[sequence and timeline handling|ModelDependencies]].
 &lt;&lt;&lt;
 So the plan is to use ''per type'' mapping tables for an association: ''symbolic-ID &amp;rarr; unique-ID''
-There should be a configurable slot to ''attach an object reference'' &amp;mdash; to be defined later
+There should be a configurable slot to ''attach an object reference'' &amp;mdash; extensions to be defined later
 Just an ''registration scheme'' should be implemented right now, working completely automatic
 &lt;&lt;&lt;
+
+!!!!notes
+* //code bloat// &amp;mdash; need a frontend and an untyped backend for the raw storage
+* one table or many tables?
+** obviously, one table is more space efficient
+** but it would be redundant (both PlacementIndex and AssetManager //are// implemented with a large hashtable)
+** moreover, ennumeration of all elements of a specific kind was one of the reasons to build this facility
+* supporting 1:n ? (e.g. one track-ID for many track objects?). Rather not directly, because this defeats lookup by ID
+see [[implementation planning|TypedLookup]]
+</pre>
+</div>
+<div title="TypedLookup" modifier="Ichthyostega" modified="201004031616" created="201004031607" tags="Rules spec impl draft" changecount="14">
+<pre>TypedID is a registration service to associate object identities, symbolic identifiers and types. It acts as frontend to the TypedLookup service within Proc-Layer, at the implementation level. While TypedID works within a strictly typed context, this type information is translated into an internal index on passing over to the implementation, which manages a set of tables containing base entries with an combined symbolic+hash ID, plus an opaque buffer. Thus, the strictly typed context is required to re-access the stored data. But the type information wasn't erased entirely, so this typed context can be re-gained with the help of an internal type index. All of this is considered implementation detail and may be subject to change without further notice; any access is assumed to happen through the TypedID frontend. Besides, there are two more specialised frontends.
+
+!Front-ends
+* TypedID uses static but templated access functions, plus an singleton instance to manage a ~PImpl pointing to the ~TypedLookup table
+* the individual //registration groups// (see below) are automatically exposed as MetaAsset.
+* TypeHandler is heavily used by the ConfigRules {{red{planned}}}; each participating primary type provides an implementation
+
+!Tables and index
+The Table consists of several registration groups, each of which contains a hashtable and deals with one specific type. Groups are created on demand, but there is initially one group holding the internal type index (translation table). There may be even sub-groups, usable to create clusterings within one group.
+
+__Individual entries__ are comprised of a ''~EntryID'' as key (actually a ~BareEntryID, without the typing) and a payload, which //doesn't store data,// but informations necessary to ''lookup and access'' the registered object. Obviously, this information is type specific, and thus the ~TypedLookup implementation can't know how to deal with it directly. Rather, we store a ''functor'' in the payload of the type index group. This functor is directly linked to the TypeHandler, i.e. any type wanting to be a primary type within Lumiera, so as to be directly usable within the ConfigRules, needs to provide a suitable functor implementation through its ~TypeHandler. These functors are then invoked by the ~TypedID frontend, when it comes to re-accessing an registered entity by ID
+
+!link for automatic registration
+An entity can be linked with the TypedLookup system to be registered and deregistered automatically. This is achieved by mixing in the {{{TypedID::Link}}}. On creation, this will set up an EntryID for this individual instance and cause creation of an empty entry within the suitable registration group. As a side-effect, uniqueness of any symbolic-ID within one group (type) is enforced. Obviously, the dtor of this registration Link cares for de-registration automatically. Be forwarned though, by creating an unique identity, this mechanism will interfere with copying and cloning of the registered entity.
+
+In most cases, the //actually usable instance// of an entity isn't identical to a implementation class (language) instance. Typically, there is a frontend, a smart-ptr, reference or similar, which in turn might link to another registration mechanism. This ''actual instance tag'' needs to be attached deliberately through the {{{TypedID::Link}}} to be stored into the payload of the registration group table entry. This involves invocation of the functor provided by the TypeHandler.
+
+!basic usage patterns
+* ''Assets'' are maintained by the AssetManager, which always holds a smart-ptr to the managed asset. Assets include explicit links to dependent assets. Thus, there is no point in interfering with lifecylce management, so we store just a ''weak reference'' here, which the access functor turns back into a smart-ptr, sharing ownership.
+* Plain ''~MObjects'' are somewhat similar, but there is no active lifecycle management &amp;mdash; they are always tied either to a placement of linked from within the assets or render processes. When done, they just go out of scope. Thus we too use a ''weak reference'' here, assumed the respective entity has mixed in {{{TypedID::Link}}}
+* Active ''Placements'' of an MObject behave like //object instances// within the model/session. They live within the PlacementIndex and cary an unique {{{LUID}}}-ID. Thus, it's sufficient to store this ''Placement-ID'', which can be used by the access functor to fetch the corresponding Placement from the session.
+Obviously, the ~TypedLookup system is open for addition of completely separate and different types.
+|&gt;| !Entity |!pattern |
+|1:1| Track|Placement|
+|~| Label|Placement|
+|~| Sequence|Asset|
+|~| StreamType|Asset|
+|1:n| Tag|Asset|
+|~| Clip|~MObject|
+|~| Effect| ~MObejct|
+|~| Transition| Asset(?)|
 </pre>
 </div>
 <div title="TypedQueryProblem" modifier="Ichthyostega" modified="200910301629" created="200910231618" tags="Rules operational" changecount="10">