I don't really see much point in including this skeleton definition. I would probably rip out all the pieces of this PR related to the "proto" format, and put them into a separate branch with the code that actually dumps the raw dependency graph. I think having both "pbtxt" and "proto" is kind of confusing, particularly since only one of them is actually related to "graph visualization".

Yes, in fact the idea to consider 'proto' format was because we wanted some fast way to get the output for the graph visualization, but the 'proto' format does not look exactly like 'pbtxt' (Tensorboard can not read this), and also in a later commit using a fast concatenation (bytes.Buffer) is possible get a similar performance to get the 'pbtxt' format of the graph. So I removed all code in regard to 'proto' format.

For what it's worth, in general I would prefer this rpc to return a proto, and generate the pbtext/dot in a command that calls into this rpc. I understand that it is a huge refactor, and we can leave it to later, but putting external format-specific code into GAPIS is generally something to avoid.

That does seem like a better solution, once we have proper serialization of the dependency graph. This serialization is a bit messy since the dependency graph currently holds onto a reference to the capture, which is how we get information about the commands associated with the nodes.

So how I would probably implement this is the dependency graph would contain
path.Command (s) that can be used by the external tool, to get the command information if it wants it.