New Adapter: Generic

[przemkaczmarek]

No description provided.

[github-actions]

Code coverage summary

Note:

• Prebid team doesn't anticipate tests covering code paths that might result in marshal and unmarshal errors
• Coverage summary encompasses all commits leading up to the latest one, a5b9255

generic

Refer here for heat map coverage report

github.com/prebid/prebid-server/v2/adapters/generic/generic.go:27:	Builder		0.0%
github.com/prebid/prebid-server/v2/adapters/generic/generic.go:34:	MakeRequests	0.0%
github.com/prebid/prebid-server/v2/adapters/generic/generic.go:50:	MakeBids	0.0%
github.com/prebid/prebid-server/v2/adapters/generic/generic.go:96:	getBidType	0.0%
total:									(statements)	0.0%

[SyntaxNode]

Thank you for implementing the generic adapter. This will be more complicated than other adapter ports due to the special case nature of the generic adapter. We'll likely want to talk through some of these comments. I'm out for the June 19 meeting though.

[SyntaxNode]

It's invalid in PBS-Go for aliases to specify a different json schema. Does PBS-Java allow generic aliases to specify their own schema?

[SyntaxNode]

The PBS-Java config is not valid for PBS-Go. This should break out into one file per alias of the generic adapter.

IMHO the root generic adapter is a special case which should not have a generic.yaml file, which likely requires extra logic.

[SyntaxNode]

Do bidders return these fields today in PBS-Java?

[SyntaxNode]

Is this the approach used by PBS-Java? It's an antipattern which is all too common in adapters. IMHO we should prefer MType, then perhaps the prebid metadata extension, and maybe finally fall back to this approach,, in which case audio needs to be supported here too.

[bsardo]

Closing. We will revisit at some point and will need to discuss as this is quite involved.