Assets: investigating the unclear distinction between asset::Struct and asset::Meta (#1156)

including a kind-of Bugfix: the ctor of TimeGrid erroneously categorised it as asset::Kind STRUCT

src/proc/asset/category.hpp

@@ -57,7 +57,7 @@ namespace asset {
     , VIDEO
     , EFFECT
     , CODEC
-    , STRUCT
+    , STRUCT                                                     //////////////////////////////////TICKET #1156 : do we need the distinction between STRUCT and META?
     , META
     };
   

src/proc/asset/meta.hpp

@@ -61,6 +61,7 @@
 #define ASSET_META_H
 
 #include "proc/asset.hpp"
+#include "proc/asset/struct-scheme.hpp"
 #include "lib/idi/entry-id.hpp"
 #include "lib/nocopy.hpp"
 
@@ -112,6 +113,7 @@ namespace asset {
   /**
    * key abstraction: metadata, parametrisation, customisation and similar organisational traits.
    * @todo just a stub, still have to figure out the distinctive properties of asset::Meta
+   *                                                             //////////////////////////////////TICKET #1156 : do we need the distinction between STRUCT and META?
    */
   class Meta
     : public Asset
@@ -127,7 +129,14 @@ namespace asset {
         }
       
     protected:
-      Meta (Asset::Ident const& idi) : Asset(idi) {}  //////////////TODO
+      Meta (Asset::Ident const& idi)
+        : Asset{idi}
+        { }
+      
+      template<typename TY>
+      Meta (lib::idi::EntryID<TY> const& nameID)
+        : Meta{idi::getAssetIdent (nameID, META)}
+        { }
       
 //    friend class MetaFactory;  ///////////////////////////////////TODO still necessary?
     };

src/proc/asset/meta/time-grid.cpp

@@ -51,9 +51,12 @@ namespace meta {
   
   
  
-  /** */
+  /**
+   * @internal to be invoked indirectly by means of the Builder<TimeGrid>.
+   * @todo drafted in 2010 -- usage of the builder feels unsatisfactory as of 2018
+   */
   TimeGrid::TimeGrid (GridID const& nameID)
-    : Meta (idi::getAssetIdent (nameID))
+    : Meta{nameID}
     { }
   
   
@@ -76,7 +79,7 @@ namespace meta {
     /** @internal helper to retrieve the smart-ptr
      * from the AssetManager, then attach a further
      * smart-ptr-to-Quantiser to that, which then can be
-     * published via the \link advice.hpp "advice system"\endlink
+     * published via the [advice system](\ref advice.hpp)
      * @note this allows to use a time grid just "by name",
      *       without explicit dependence to the Session / Assets
      */

src/proc/asset/meta/time-grid.hpp

@@ -22,7 +22,7 @@
 
 
 /** @file time-grid.hpp
- ** Establishing a reference scale for quantised time values.
+ ** To establish a reference scale for quantised time values.
  ** Contrary to the continuous Time values (Lumiera internal time scale),
  ** quantised time can only take on some discrete values corresponding
  ** to blocks or frames, according to the respective \em timecode format.
@@ -34,7 +34,8 @@
  ** Time grid specifications are integrated into Lumiera's framework
  ** for meta assets, automation, configuration and similar metadata.
  ** 
- ** \par using time grids
+ ** ## using time grids
+ ** 
  ** TimeGrid is an interface (ABC), but provides some actual factory
  ** functions, which can be used as a convenience shortcut to fabricate
  ** the kind of simple time grid used most often.

src/proc/asset/struct-scheme.hpp

@@ -155,9 +155,9 @@ namespace asset{
      */
     template<typename TY>
     inline Asset::Ident
-    getAssetIdent (lib::idi::EntryID<TY> const& entryID)
+    getAssetIdent (lib::idi::EntryID<TY> const& entryID, asset::Kind assetKind =STRUCT)
-    {
+    {                                                    //////////////////////////////////////////TICKET #1156 : do we need the distinction between STRUCT and META?
-      Category cat (STRUCT, idi::StructTraits<TY>::catFolder());
+      Category cat (assetKind, idi::StructTraits<TY>::catFolder());
       return Asset::Ident (entryID.getSym(), cat);
     }
     

src/proc/asset/struct.hpp

@@ -108,6 +108,7 @@ namespace asset {
    *       The idea is to have a generic mechanism for attaching properties and relations.
    *       This will become relevant once we build the real query subsystem.
    *       Right now (as of 1/2015), asset::Struct is just an ID provider.
+   *                                                             //////////////////////////////////TICKET #1156 : do we need the distinction between STRUCT and META?
    */
   class Struct : public Asset
     {

tests/41asset.tests

@@ -58,6 +58,6 @@ END
 
 
 TEST "Simple TimeGrid" TimeGridBasics_test <<END
-out-lit: simple PAL Grid: (STRUCT/time-scales:lumi.grid(25FPS_0) v1)
+out-lit: simple PAL Grid: (META/time-scales:lumi.grid(25FPS_0) v1)
 return: 0
 END

wiki/renderengine.html

@@ -860,7 +860,7 @@ Even if the low-level memory manager(s) may use raw storage, we require that the
 → see MemoryManagement
 </pre>
 </div>
-<div title="Asset" modifier="Ichthyostega" created="200708100337" modified="201808101636" tags="def classes img" changecount="2">
+<div title="Asset" modifier="Ichthyostega" created="200708100337" modified="201808111601" tags="def classes img" changecount="4">
 <pre>Asset management is a subsystem on its own. Assets are &quot;things&quot; that can be loaded into a session, like Media, Clips, Effects, Transitions. It is the &quot;bookkeeping view&quot;, while the Objects in the Session relate to the &quot;manipulation and process view&quot;. Some Assets can be //loaded// and a collection of Assets is saved with each Session. Besides, there is a collection of basic Assets always available by default.
 
 The Assets are important reference points holding the information needed to access external resources. For example, an Clip asset can reference a Media asset, which in turn holds the external filename from which to get the media stream. For Effects, the situation is similar. Assets thus serve two quite distinct purposes. One is to load, list, group search and browse them, and to provide an entry point to create new or get at existing MObject in the Session, while the other purpose is to provide attribute and property information to the inner parts of the engine, while at the same time isolating and decoupling them from environmental details. 
@@ -900,6 +900,8 @@ is how to implement the relationship between [[MObject]]s and Assets. Do we use
 
   //9/07: currently implementing it as follows: use a refcounting-ptr from Clip-~MObject to asset::Media while maintaining a dependency network between Asset objects. We'll see if this approach is viable//
 
+{{red{NOTE 8/2018}}} there seems to be a fuzziness surrounding the distinction between StructAsset and MetaAsset.
+I am suspicious this is a distinction //merely derived from first principles...// &amp;rarr; {{red{Ticket #1156}}}
 </pre>
 </div>
 <div title="AssetCreation" modifier="Ichthyostega" created="200709040307" modified="201002272321" tags="operational impl">
@@ -4210,10 +4212,11 @@ For the case here in question this seems to be the __R__esource __A__llocation _
 And, last but not least, doing large scale allocations is the job of the backend. Exceptions being long-lived objects, like the session or the sequences, which are created once and don't bear the danger of causing memory pressure. Generally speaking, client code shouldn't issue &quot;new&quot; and &quot;delete&quot; when it comes in handy. Questions of setup and lifecycle should allways be delegated, typically through the usage of some [[factory|Factories]], which might return the product conveniently wrapped into a RAII style handle. Memory allocation is crucial for performance, and needs to be adapted to the actual platform -- which is impossible unless abstracted and treated as a separate concern.
 </pre>
 </div>
-<div title="MetaAsset" modifier="Ichthyostega" created="201012290320" modified="201808101637" tags="def" changecount="2">
+<div title="MetaAsset" modifier="Ichthyostega" created="201012290320" modified="201808111603" tags="def" changecount="4">
-<pre>This category encompasses the various aspects of the way the application controls and manages its own behaviour. They are more related to the way the application behaves, as opposed to the way the edited data is structured and organised (which is the realm of [[structural assets|StructAsset]])
+<pre>This category encompasses the various aspects of the way the application controls and manages its own behaviour. They are more related to the way the application behaves, as opposed to the way the edited data is structured and organised (which is the realm of [[structural assets|StructAsset]]) &amp;rarr; {{red{Ticket #1156}}}
 * StreamType &amp;rarr; a type system for describing and relating media data streams
 * ScaleGrid &amp;rarr; to manage time scales and frame alignment
+* {{{ErrorLog}}} &amp;rarr; collect incident records
 
 !accessing meta assets
 It turns out that all meta assets follow a distinct usage pattern: //they aren't built as individual entities.// Either, they are introduced into the system as part of a larger scale configuration activity, or they are //derived from category.// The latter fits in with a prototype-like approach; initially, the individual entry just serves to keep track of a categorisation, while at some point, such a link into a describing category may evolve into a local differentiation of some settings.

wiki/thinkPad.ichthyo.mm

@@ -32085,6 +32085,57 @@
 <node CREATED="1533918403071" ID="ID_277977903" MODIFIED="1533918404515" TEXT="Meta"/>
 </node>
 <node CREATED="1533918425908" ID="ID_1069430929" MODIFIED="1533918430743" TEXT="Einordnung">
+<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1534001954612" ID="ID_1527156035" MODIFIED="1534001972543" TEXT="Probleme">
+<icon BUILTIN="messagebox_warning"/>
+<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1534001984536" ID="ID_1186986383" MODIFIED="1534002025741" TEXT="#1156 clarify distinction between asset::Struct and asset::Meta">
+<icon BUILTIN="flag-yellow"/>
+</node>
+<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1534002074828" ID="ID_867232883" MODIFIED="1534002083668" TEXT="Asymetrie in asset::Category">
+<icon BUILTIN="flag-yellow"/>
+<node CREATED="1534002102456" ID="ID_101543995" MODIFIED="1534002106435" TEXT="benutzer-orientiert"/>
+<node CREATED="1534002106999" ID="ID_354946108" MODIFIED="1534002112546" TEXT="GUI ist aber noch nicht gebaut"/>
+<node CREATED="1534002113086" ID="ID_1894075831" MODIFIED="1534002172804" TEXT="Audio und Video werden eigens unterschieden">
+<richcontent TYPE="NOTE"><html>
+  <head>
+    
+  </head>
+  <body>
+    <p>
+      ...obwohl die betreffenden Assets in die Kategorie &quot;Medien&quot; fallen,
+    </p>
+    <p>
+      und wir einen eigenen StreamType definieren wollen, also explizit die Art der Medien offen lassen.
+    </p>
+    <p>
+      Ganz prominent fehlt hier also z.B: MIDI
+    </p>
+  </body>
+</html>
+</richcontent>
+</node>
+<node CREATED="1534002180893" ID="ID_1074039128" MODIFIED="1534002196087" TEXT="daf&#xfc;r erscheint die Unterscheidung STRUCT vs. META schwammig"/>
+</node>
+<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1534002037961" ID="ID_95419141" MODIFIED="1534002049833" TEXT="Erzeugung und Lebenszyklus">
+<icon BUILTIN="flag-yellow"/>
+<node CREATED="1534002202098" ID="ID_1411648485" MODIFIED="1534002215541" TEXT="diese Auto-Regisierung"/>
+<node CREATED="1534002225888" ID="ID_138566211" MODIFIED="1534002272126" TEXT="smart-Ptr als Handle nicht immer sinnvoll">
+<richcontent TYPE="NOTE"><html>
+  <head>
+    
+  </head>
+  <body>
+    <p>
+      ...n&#228;mlich genau <i>nicht</i>&#160;f&#252;r alle Assets,
+    </p>
+    <p>
+      die Aufgrund von Klassifikationen automatisch bereits existieren
+    </p>
+  </body>
+</html>
+</richcontent>
+</node>
+</node>
+</node>
 <node CREATED="1533918431595" ID="ID_1121251191" MODIFIED="1533918772587" TEXT="ErrorLog(Asset)">
 <linktarget COLOR="#68788a" DESTINATION="ID_1121251191" ENDARROW="Default" ENDINCLINATION="-1644;0;" ID="Arrow_ID_146013003" SOURCE="ID_1117749960" STARTARROW="None" STARTINCLINATION="-4766;280;"/>
 <node CREATED="1533997520937" ID="ID_130549036" MODIFIED="1533997523524" TEXT="Typ">
@@ -32183,7 +32234,11 @@
 <icon BUILTIN="hourglass"/>
 </node>
 </node>
-<node CREATED="1533997570242" ID="ID_503070656" MODIFIED="1533997575269" TEXT="spezielle Detail-Logs"/>
+<node CREATED="1533997570242" ID="ID_503070656" MODIFIED="1533997575269" TEXT="spezielle Detail-Logs">
+<node CREATED="1534002311748" ID="ID_440257353" MODIFIED="1534002317208" TEXT="geplant/Idee">
+<icon BUILTIN="idea"/>
+</node>
+</node>
 <node CREATED="1533997581280" ID="ID_398592361" MODIFIED="1533997591029" TEXT="Idee: Verallgemeinerung auf Logs">
 <icon BUILTIN="idea"/>
 <node CREATED="1533997595735" ID="ID_459951978" MODIFIED="1533997703292" TEXT="selbstreferentielle Struktur">