Frame in memory interface

[tmadlener]

BEGINRELEASENOTES

• Introduce the podio::Frame as a generalized (event) data container with the necessary prerequisites to extend this basic implementation with all the planned functionality later.
  • This version does not yet include any I/O functionality but only introduces the thread-safe in-memory interface.

ENDRELEASENOTES

This is a first version of the in-memory interface of the Frame proposal. I am putting this here to gather early feedback, mainly on the user interface and on some of the proposed functionality. At this point only the basic skeleton for the podio::Frame is present and much of the foreseen functionality is still missing. However, the interface should be somewhat stable already as most of that functionality should be hidden, or not observable through the interface. One thing that could still influence the interface could be the choice of policies that we want to offer. I have put some of my proposals below.

Having this discussion early enough might make it possible to split this feature into several pull requests instead of having one extremely large one.

podio::Frame interface

The Frame is implemented via type-erasure. This allows us to have different policies but only one user facing class with value semantics and the possibility to construct from different raw data types ¹. The current public interface of the Frame looks essentially like this:

class Frame {
public:
  template<typename CollT>
  const CollT& get(const std::string& name) const;

  template<typename CollT>
  const CollT& put(CollT&& coll, const std::string& name);

  template<typename T>
  void putParameter(const std::string& key, T value);
  
  template<typename T>
  const T& getParameter(const std::string& key) const;
};

Some notes (about the actual implementation that are not visible in the above version):

• The put and get methods use std::enable_if to only be available for collections added by podio.
• The put method uses std::enable_if to force users to explicitly pass a temporary or relinquish ownership via std::move.
• The {put|get}Parameter functionality provides the extra data / meta data functionality and is using the GenericParameters class under the hood.
  • The templates are using std::enable_if to only be available for the types that are actually supported (int, float, std::string and std::vectors of those)
  • The return value of getParameter is either a const T& or a T (for int and float).
  • There are a few dedicated overloads for putParameter to enhance the usability, e.g. for passing raw string literals or initializer lists.

Planned policies

There are a few policies that I have already in mind, but this is still open for discussion

• Unpacking policy that controls how the raw data that are passed are unpacked. E.g. could be eagerly on Frame construction or lazily on demand. Would be completely invisible for users.
• Handling of collisions when putting collections into the Frame. E.g. could throw an exception, silently drop the new collection or replace the existing collection. Could potentially also be part of the put interface to have more fine grained control, instead of having a "global" policy
• Handling of missing collections. E.g. could throw an exception or simply return an empty new collection. Could potentially become part of the get interface to have more fine grained control, instead of a "global" policy.
• Locking policy. E.g. could drop all (externally observable) locking if the Frame is only used from one thread or to read only, or could go with the default locking which might have an impact on single threaded use.

Preliminary TODO list

• Policies -> postponed to later PR
• I/O functionality -> Done in Prototype version of Frame I/O #287
• Thread safe get/set functionality
• Thread safe parameters access
• documentation
• Combined c++20 concepts and c++17 compatible implementation of type constraints? Not sure how easily possible that is. Probably can be added later. -> postponed to later PR
• Release notes
• Targets develop
• Need Add templated get/set functionality for GenericParameters and deprecate non-templated versions #262 on top of develop diff of once that is merged

Footnotes

1. This first proposal is still missing these features at the moment. ↩

[tmadlener]

Closing this, as it is fully contained in #287 and will be merged as an “atomic” commit introducing the Frame