Rethink API structure

[tim-weis]

As it stands, the API operates on different levels of abstraction.

At the bottom there's the CFB container, that implements a pseudo filesystem inside a file. While not strictly necessary to expose data at this level, it is certainly convenient to have this data available. The ovba-cli tool makes use of it, though it doesn't (currently) implement any functionality on top of reporting this data ("hey look, there's a storage named xyz that contains streams a, b, and c).

A level up, there's (potentially decompressed) data, describing the VBA project, its modules and references. The vast majority of this data is provided as is, by means of returning structures that map almost 1-to-1 to the binary layout.

Yet another level up are convenience implementations, currently Project::module_source() and Project::module_source_raw(). Those are essentially where the API feels most natural. The types exposed are native Rust types and combinations thereof.

Currently, all levels are exposed as associated functions on the Project type. This doesn't feel very natural to use. This issue tries to find ways to structure the API to make it easier for clients to understand at which level of abstraction they are operating.

[nekevss]

Hi! Couple question for you.

1. Are you still actively developing this library/planning to in the future.

2. Any plans to expand on the parser to handling inputting something like a .xlsm or .docm file?

[tim-weis]

Thanks for reaching out, @nekevss! Here are the answers to your questions:

Are you still actively developing this library/planning to in the future.

At this time, I don't have any immediate need to move this library forward. There are a few points I'd like to address at some time (documentation, API structure, error reporting, testing) once I find time to do so. If any defect reports come in, then those are handled with priority.

Any plans to expand on the parser to handling inputting something like a .xlsm or .docm file?

I understand that this would be convenient to have. While I'm not strictly opposed to the idea, it feels out of scope for this library, and I'm reluctant to take additional dependencies (Zip library, XML parser).

Extracting a binary VBA blob from an Office Open XML document isn't all that difficult, even if not trivial either. I don't feel that it's generally useful in its current state, but I'm making this repository public, in case you need to find out how to deal with Office Open XML documents.