Discussion: Interplay between Readers, Writers, EventStore and Collections about podio

[hegner]

Let me comment on the various points.

1. Ownership: it very much depends on the vision for how PODIO will support multiple I/O backends. Either the EventStore is merely a thin facade on top of the reader / writer which have all the business logic. Or - what makes more sense - the EventStore does most of the book keeping and thus the I/O backends mainly bridge to the memory models of the I/O libs. At least in first order. This allows as well to mix different backends and format conversion. @tmadlener made a good point about the writer acting as a sink. I think that makes a lot if sense. We should however make the interfaces more clear about ownership transfer.

The metadata handling to me needs a rethinking entirely.

2. Synchronization: for this I will need to explain possible models in a meeting if OK with everybody

3. const correctness: goes along with it

[tmadlener]

The metadata handling to me needs a rethinking entirely.

Yes, I agree. At the moment it is not clear what are the use cases that we want to support (and also which we do not want to support). I think we first need to clarify that a bit more, before we can think about how to best implement this.

@tmadlener made a good point about the writer acting as a sink. I think that makes a lot if sense.

Actually, after thinking about this some more, I am not sure if it is the best way to do it. It is not entirely clear to me whether we can support a use case where the data remain valid after we have written them. E.g. The use case for writing different tiers of data in one processing unit, or writing to more than one file at the end.

[hegner]

The point about the sink is that the write can happen asynchronously as defined by the logics of the writer rather than tied to the lifetime of an event.

[andresailer]

See also discussion https://indico.cern.ch/event/983031/#4-discussion

[tmadlener]

No longer relevant with deprecation of the EventStore and the Frame based model.