Consider renaming "EventFormatter"

[toumorokoshi]

For lazy events, the current API requires the attribute creation function to be called "EventFormatter":

An API to record a single Event whose attributes or attribute values are
lazily constructed, with the intention of avoiding unnecessary work if an event
is unused. If the language supports overloads then this SHOULD be called
AddEvent otherwise AddLazyEvent MAY be considered. In some languages, it
might be easier to defer Event or attribute creation entirely by providing a
wrapping class or function that returns an Event or formatted attributes. When
providing a wrapping class or function it SHOULD be named EventFormatter

I feel that the name is a little bit of a misnomer, as there are multiple reasons why event attribute population would be better of lazy (e.g. having to perform some synchronous request to retrieve said values), and formatting may just be one.

As an alternative, I might call it "EventRetriever".

[Oberon00]

I wonder if we should just remove lazy Events from the spec. Since the SDK only supports head-based sampling anyway, a check of the IsRecording property on the caller side should be even more effective in avoiding work.

[toumorokoshi]

I think the use cases for such a class are fairly limited, and I have a feeling formatting will not be the reason why you want deferred attributes.

But on the other hand, if it is a common enough need, we should have it specified somewhere.

As a slightly more complex alternative, one could create a lazy API, and use that for the non-lazy case as well, since that would just be returning back an already-constructed object.

[bogdandrutu]

@Oberon00 lazy Events can be used even with head-based sampling. You can postpone the formatting until the exporter phase.

[Oberon00]

This only makes a difference vs checking IsRecording in edge cases tough, like if the BatchSpanProcessor queue is full (and even then only if the implementation does not call toSpanData or equivalent right at the Span.end call).

[bogdandrutu]

@Oberon00 I think IsRecording should be good enough. Can you create a PR to remove the lazy or make it optional?

[arminru]

@bogdandrutu Do you know if any of the language implementation actually implement lazy event creation/EventFormatter? Java, for example, does not and thus actually breaches this MUST requirement.

I'd be in favor of removing the lazy event API entirely as well as the lazy link API. I'm not aware of any reason for the inconsistency between links/events attributes and span attributes as there's no lazy SetAttribute API and such either. It seems checking IsRecording should be sufficient.