astool tool improvement idea: pruning

[cjslep]

The idea is that the tool would do the existing steps:

• Generate ActivityStreams types using the v1 code generation tool
• Build an App against that, using types as necessary

Then the novel functionality:

• Run the tool against the App's codebase to learn what types it is actually using
• Overwrite the generated ActivityStreams types to only generate the ones it is using

This could cut down on compilation and linking time as well as binary bloat, since the Manager is linked against every instantiation.

Note that a tricky bit will be to make sure it works for others who want to provide alternate implementations to go-fed's interfaces.

[aschrijver]

I wonder if this is making it too easy, and goes against design principles and the USP of adding your own vocabularies. The pruning might be an additional CLI action that can be part of apcore where the ease-of-use is key (and maybe most people won't go further than creating microblogging-like apps that fit into the AS2 mold).

In general for non-AS vocabularies that people use to build their extension, the OWL definition would be an intricate part of the design process of the application. Very carefully designed and fit-to-the-task, so no pruning needed.

Where the extensions build on top of ActivityStreams this careful-design-approach is still a best-practice then. Instead of auto-pruning it might be better to have a directive telling the code generator to ignore parts of the AS2 spec for code generation (i.e. to manually prune). This way you don't have to cut things from the spec, and just remove the directives where needed as your app + extension requires.

(From my perspective and understanding ignore directives is more of a should-have than auto-pruning, which is a could-have)

[cjslep]

I see what you're saying. The difficulty is -- if I'm remembering right, this was some nasty code -- that astool is a pipeline that very roughly goes in these stages:

--------------
|   Start    |
--------------
      |     -----------------------------------
      |     |                                  |
      V     V                                  |
--------------       ----------------------    |    --------------------
|Read a Spec | ----> | Resolve references | ---|--> | Internal structs |
--------------       ----------------------   or    --------------------
                                                           |
----------------       ----------------------------        |
| Write output | <---- | Put into codegen structs | <-------
----------------       ----------------------------

As such it doesn't have a way to really read the output generated code to do the prune, nor currently does it have a way to save the internal struct state that could read to either a reproducible non-pruned code-gen command or a pruned version.

That's a long way of saying: it's far easier to introduce something like a --prune flag that does the pipeline behavior today, but opted into the prune.

Now the idea of splitting out such a behavior for something like apcore use is interesting. That implies the astool core behavior needs to be isolated from the command-line app implementation. The astool binary would not leverage the prune logic in the library, but the apcore binary would.

EDIT: I think my diagram is slightly misleading (the loop arrow should come after the "internal structs") but making that diagram was so hard I can't be arsed to fix it.

[aschrijver]

Now the idea of splitting out such a behavior for something like apcore use is interesting.

Or it can be stand-alone and provide all options, depending on how you combine things.