AudioContent should have had a non-pointer receiver, to be consistent with other content types. Add this to our log of rough edges to reconsider for v2. Fixes #641
1.2 KiB
1.2 KiB
Rough edges: API decisions to reconsider for v2
This file collects a list of API oversights or rough edges that we've uncovered post v1.0.0, along with their current workarounds. These issues can't be addressed without breaking backward compatibility, but we'll revisit them for v2.
-
EventStore.Openis unnecessary. This was an artifact of an earlier version of the SDK where event persistence and delivery were combined.Workaround:
Openmay be implemented as a no-op. -
Enforcing valid tool names: with SEP-986 landing after the SDK was at v1, we missed an opportunity to panic on invalid tool names. Instead, we have to simply produce an error log. In v2, we should panic.
-
Inconsistent naming.
ResourceUpdatedNotificationsParamsshould probably have just beenResourceUpdatedParams, as we don't include the word 'notification' in other notification param types.- Similarly,
ProgressNotificationParamsshould probably have beenProgressParams.
-
AudioContent.MarshalJSONshould have had a pointer receiver, to be consistent with other content types.