Ensar Sarajčić

> I would strongly disagree here, or this would be a separate TTL. A cache entry has an expiration because it is "volatile" data that reduces in accuracy over time,...

> Hey, I did a quick pass as promised. A general comment here is that the proposed change semantically is more like a "global VRL state" vs a "VRL cache"....

> Yes, as @pront mentioned, I believe that extending enrichment tables is the better path here. At a high-level, there are some important characteristics of VRL that we want to...

> Yes, as @pront mentioned, I believe that extending enrichment tables is the better path here. At a high-level, there are some important characteristics of VRL that we want to...

Thank you. Alright, I was initially going to add a new sink, but that approach makes sense. Thanks for the `evmap` suggestion, I was looking for something like that for...

I have prepared the implementation of `StreamSink` trait for this component, but I am not sure what would be the best way to connect it in as a sink. Looking...

I have also moved these events and metrics from previous cache implementation to this memory enrichment table. Since most of these events contained the name of the cache (or in...

> The most "correct" way to do this would likely be to change how enrichment tables are handled in the topology builder, adding the ability to have an (optional) set...

> @esensar let me know if you are blocked on this Thanks, I will take a shot with the above suggestion. I was planning on adding sink for this enrichment...

I have finally made some small progress on this. I have added a `SinkConfig` implementation for `MemoryConfig`, so it is now shared configuration for building both the enrichment table and...