Context and objective

This document is a working draft for a recommendation of what a "1.0 Stable" version of a Symphony API Language Binding should cover. The goal is that new language bindings have a central document to orient themselves when starting the project, and that projects that are getting close to "1.0 Stable" release have a checklist they can use to finalize.

The primary focus is to allow users of such SDKs to be very clear on what to expect when starting to build on them. This would cover both functional and non-functional expectations.

Current projects recap

SDK	Project	Status	Project owner
Java	Design Detail/Wiki	(Active) V1.0.0 (Stable) v1.0.1-SNAPSHOT	Former user (Deleted)
.NET		0.4.0	Former user (Deleted)
Python			Matt Joyce (Deactivated)
Clojure		0.1.0-SNAPSHOT	Peter Monks
PHP	Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.		Florian de Miramon
Javascript / Node			Former user (Deleted)

Definition

Binding:
- A language binding is a language-specific implementation of the Symphony REST API, that facilitates implementations is that particular language.
- It can evolve into more elaborate clients that wrap into higher order functions
Framework:
- It can also evolve into broader framework, that allow addition of meaningful new capabilities (eg AI, NLP, etc.)

Current document refers to binding primarily.

Users expectations

As users of a "1.0" SDK, I would expect the following:

Supported by LLC for level 1-2 support
- At this stage in the growth/maturation of the Symphony Product, Ecosystem, and Community, users of the Java SDK who are also Symphony customers will expect using the SDK to be fully supported by Symphony LLC. This means:
  - questions to the Symphony support organization (developers@symphony.com) are solved following the normal SLA
    - ie: As a customer using this "1.0 stable" SDK, I am expecting Symphony LLC to know enough about it that LLC can explain to me how it works, troubleshoot my issues if they are related to configuration or my code, and help me formulate bugs to the project team (level 3) if needed.
    - Level 3 support would either be the project team, or, as the case may arise, by LLC through a standard PR.
  - using the SDK is fully documented on the central documentation for developers on the Symphony Platform https://developers.symphony.com/ (or equivalent)
Functional integrity
- comprehensive functional coverage of public REST API, as documented on https://developers.symphony.com/ is complete, ideally for the most recent release of Symphony
- no unsupported or private APIs are used
- new API endpoints or new version are incorporated into the SDK with a reasonably fast timeframe
Documentation integrity
- Documentation in the code itself (readme.md) is aligned with the other documentation (https://developers.symphony.com/) on nomenclature, terminology, links, etc
Quality standards
- Functional quality: All public functions of the REST API is working as expected.
- Non-functional quality: API performance is as expected and works in the most common deployment scenarios (cloud, on-prem).

More precisely, this means:

Readiness checklist

Foundation contribution criteria
- Active status: see Activation
Functional coverage meets, at time of release
- 0 Blockers on any functions
- 0 Critical on any functions
- 0 Major on any functions
- Need to discuss specific criticality definition
Non-functional definition
- Need to discuss what we recommend here, notably regarding:
  - load balancing, HA
  - supported topologies
  - performance/latency
- Standard built-in diagnostic
  - Connectivity status
  - Need to have a primary focus on real time capabilities and request/response (tie back to common concepts to other communications like SIP/SIMPLE, XMPP)
Functional integrity
- Primary "communication" use cases supported
  - Admin endpoints not necessary
- Other WG members/LLC to perform deep dive
- Integration test list, need to particularly address the crosspod aspect
  - Former user (Deleted) / Peter Monks think about xPod abilities in test pods
  - Former user (Deleted) / Former user (Deleted) propose a first set of integration tests
- LLC to publish Set Presence endpoint
Documentation integrity
- LLC to add SDK documentation into https://developers.symphony.com/ (or equivalent)
Working hello world sample
- Would be great to have a similar pattern

Launch activities

In addition to "standard" SSF communications:
all users of the Symphony Platform should be made aware of this significant milestone. For example:
- Outreach to Symphony LLC customers
- Joint coms on other media (eg Twitter)

Community support

Though all bindings / clients / SDK projects are autonomous, it might be relevant allow the community of engineers working on the projects to interact easily.
- We could use the WG DL or set up a specific once for SDK projects, to keep it simple.

Browser not supported