Tyler Yahn

It is not possible to use a protobuf definition without included a protobuf library as a dependency. Therefore, it does not seem viable to use any protobuf representation is the...

There are two possibilities I am currently looking into: - Using `encoding/gob` - Using `encoding/json` with an OTLP encoding

[Comparison of `encoding/gob` vs `encoding/json` for serialization of SDK data-model](https://github.com/MrAlias/opentelemetry-go-instrumentation/pull/408): ```terminal $ go test -run="^$" -bench=. goos: linux goarch: amd64 pkg: go.opentelemetry.io/auto/internal/pkg/data cpu: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz BenchmarkGOBMarshalUnmarshal-8...

It was also pointed out by @pellared that the `encoding/gob` use would have compatibility issues. If the sender/receiver used different versions of the data-model they would not be compatible.

No, it shouldn't be. The alternate approach being worked on supports those features just as well as pdata does. Those PRs are independent of this. This does block the `sdk`...

Yes, they are using `pdata` functions, and they will need to be updated when alternate data-model is added. However, the overall functionality and testing should remain similar, if not the...

FWIW, the whole SDK (i.e. probe, start/end func, struct decl) will also need to be updated.

Resolved by #1195

> That's a great idea. I think one of the steps in getting there is to refine our Probe interface, maybe worth opening another issue for that? I have some...

SIG meeting notes: - We need to decouple the `structfield.ID` in the Manifest. - This needs to look at offset generation - Possibly move offsets into a per-probe generation which...