2021-12-09 Eiffel monthly community meeting: SDKs

###### tags: `Monthly Community Meetings` # 2021-12-09 Eiffel monthly community meeting: SDKs ## Attendees - Magnus Bäck, Axis - Tobias Persson, Axis - Emil Bäckmark, Ericsson - Mattias Linnér, Ericsson - Erik Sternerson, doWhile - Kenneth Wei-Kiat Lam, Ericsson - Fady Kamil, ICT Cube / doWhile - Fredrik Fristedt, Axis ... ## Agenda - A look at existing SDK and SDK-adjacent options for events - [eiffelevents-sdk-go](https://github.com/eiffel-community/eiffelevents-sdk-go) - [eiffelevents-sdk-dotnet](https://github.com/eiffel-community/eiffelevents-sdk-dotnet) - [eiffel-remrem-semantics](https://github.com/eiffel-community/eiffel-remrem-semantics) - [eiffel-pythonlib](https://github.com/eiffel-community/eiffel-pythonlib) - What should be in scope of an event SDK? - Deserializing JSON events into proper data structures and serializing them back to JSON? - Validation? Only based on JSON schema or should it support additional rules (e.g. valid link types and targets, required links, ...)? - Message broker specific tasks? - Helping the user generate a Sepia-compliant routing key for RabbitMQ? - https://eiffel-community.github.io/eiffel-sepia/rabbitmq-message-broker.html - https://www.youtube.com/watch?v=dz5rm13Gw-Y - Should publishing events with AMQP/RabbitMQ be part of the SDK? Consuming? - Should the use of publish/confirm be part of the SDK? - It only makes sense to include the Eiffel specific parts, i.e. the Sepia routing key handling - If included in the SDK it should probably be optional to use - We leave this as an open question for now - What should an event SDK do about event types or event versions it doesn't know anything about? - Should SDKs support Eiffel extensions? - https://github.com/Ericsson/eiffel-operations-extension - Unknown event types could be appended with a meta.tag. Defined in Sepia so all SDKs do it the same way? - The SDK should probably not try to handle the error of not finding a referenced schema, but instead just propagate the error back to the client - Should an SDK validate things such as the use of data.batches vs. data.batchesUri in TERCC, or is it sufficient that we document it towards the user? - The SDK should not validate that the URI is accessible, as it could often be the case the only the consumer would have access to it - If we want to publish SDKs to e.g. nuget.org (or resp. package services for other languages) should that be done through an "Eiffel community account" (and if so, how do we get that set up?) or should we do it through our own personal or company accounts? - For convenience it would be good to use an Eiffel Community account for it. It would help when creating delivery pipelines for the SDK. - It depends on how widely spread a certain programming language is within the community. If only used by one org/company it might not make sense to use a common account. ## Non-covered topics - How should we deal with Eiffel editions, and more generally different versions of events? - If SDKs should support more than one edition, how far back? - Given an SDK that supports multiple editions, how can be make it easy for people to pick the right event versions when creating new events? - Should empty/null values be omitted when serializing to JSON? In other words, are we allowed to make a distinction - Can SDKs decide to represent Eiffel data types in a more user-friendly way but sacrifice protocol compliance? - A concrete example is data.customData, which the protocol defines as “An array of key-value pairs” (which presumably allows multiple keys with the same name) but that would be nicer to present as a map/dictionary (which only allows unique keys). In this case, the SDK would be able to produce fully compliant events, but not always decode fully compliant events (i.e. those with multiple entries with the same key). - What about when/if we introduce the possibility to use custom schemas for the events? [Protocol Issue 280](https://github.com/eiffel-community/eiffel/issues/280) - Generating both the schema and protocol docs from a common source could aid the IDE to show context specific help for events and properties - [Protocol Issue 282](https://github.com/eiffel-community/eiffel/issues/282) ### Actions - None... Let's continue discussing on Slack and community maillist ### Future ideas - Document some best practices that are applicable to any SDK. - Should it send events or just create them? - Generate routing key regardless of if event sending is included or not? - Common version handling in all SDKs? - Compatibility matrix - Provide link lookup possibilities (through some ER) or not?