• Capture the current and desired API on all 3 platforms
• Document the decisions taken as part of the initial version rollout on each platform
• Convene a discussion with engineers to decide on stable API for first wide release version

The client library should have one public interface with a common definition in terms of the abstract data types, although the names and precise structure of the types may differ between platforms/languages. Having these data types will help us do a better job of maintaining across 4+ different platforms.

Teams will be free to wrap this interface in the way they see fit, much as they do today, in order to conform to whatever notion of type safety or structure they feel is necessary.

Here is some pseudo-code that captures the major changes that would be necessary.

JS

// Current
void submit( String name, Object data );
// Desired
void submit( String name, Object data );

PHP

// Current
void submit( string $streamName, array $event, Psr/Log/Loggerinterface $logger = null )
// Desired
void submit( string $name, array $data );

Java

// Current
void submit( Event event );
// Desired
void submit( String name, HashMap<String, Object> data );

Swift

// Current
void submit<E: EventInterface>( stream: Stream, event: E, domain: String? = nil )
// Desired
void submit( name: String, data: NSDictionary );

The first argument is a name, no longer of a stream but of either an instrument or of the event (this is still being discussed). A stream will use this name to source events.

The second argument is a set of data. We want this to use the simplest collection type that supports key value pairs, because this makes things easier for us inside the library.