Erik Schamper

> The biggest win of lazy parsing IMO is not performance per se, but enabling "selective parsing" out of the box, i.e. the user is freed from having to write...

I have to say I respectfully disagree. In my experience, such a way of parsing only practically works well a very small amount of times. It's mostly a very nice...

> The goal is indeed to document our knowledge of file formats. but preferable using code, so that the code _is_ the documentation. In my experience, written documentation typically gets...

> I can see that Python lacks the expressiveness needed to write declarative code, apart from performance concerns. I looked at the Python Construct library and while I wouldn´t use...

Also, keep in mind that our goal is to create Pythonic interfaces for often not-Pythonic file formats or structures. So we will always need to wrap any sort of parsing...

Maybe you should also take a look at nom: https://github.com/rust-bakery/nom or serde: https://serde.rs.

The `NamespacePlugin` class, I presume?

The biggest problem with the current implementation is this: https://github.com/fox-it/dissect.target/issues/1015

The benefit of having some sort of flexibility to "implement" stuff in the "aggregator" namespace is that you can provide some additional helpers or convenience functions, example: - [`webserver.logs`](https://github.com/fox-it/dissect.target/blob/61511383fba6237036d713689953009a45a85453/dissect/target/plugins/apps/webserver/webserver.py#L63-L67) -...

> This is essentially a project-wise style choice, of which i am not aware how much complexity it will add to this plugin and to powershell history Not much complexity...