watson-developer-cloud / swift-sdk Goto Github PK

Testing should be performed as functions are implemented. This issue is just a reminder to verify that all tests pass before considering the library to be complete!

Start fresh with a new project. Be sure to follow updated bundle identifier and naming conventions.

When using the TTS service and the RESTful endpoints, the returned WAV file's header contains zero for the duration of the sound. This causes iOS to not be able to play the sound.

What bundle identifier should we use? (Should it match the Java/NodeJS wrappers?)

Given the bundle identifier, should we make changes to the naming conventions? Should we drop "Watson" from the name of all of the classes/structs?

This is a trade-off between usability and maintenance.

The Java wrapper uses classes, but it adds a lot of work when building support for new services. The NodeJS wrapper just returns JSON. What should we do?

Can rely heavily on the SpeechRecognition application in the repository.

These will follow as closely as possible to the existing SDK's from the other platforms

I will create a separate ticket from unit tests for tracking purposes

Many of Watson's services include support for streaming and WebSockets. Should we build this into the SDK? Should we rely on an external library for WebSockets support?

BlueMix does not support the standards required by Apple's "App Transport Security" in iOS 9. As a result, we need to modify the App Transport Security for each example application. Instead, we should submit a request to update BlueMix's security standards so that our SDK's clients do not have to make exceptions or disable App Transport Security.

For more information on App Transport Security see this blog post.

Here is the error that was produced by the SpeechTranscriptionDemo application when App Transport Security was not disabled or modified:

2015-09-13 09:42:03.886 SpeechTranscriptionDemo[29039:1519370] CFNetwork SSLHandshake failed (-9824)
2015-09-13 09:42:03.887 SpeechTranscriptionDemo[29039:1519370] NSURLSession/NSURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9824)

Write function declarations (i.e. functions with names and arguments but no implementation) to design the Speech to Text API.

Any deviation from the Java / Objective-C APIs should be recorded, discussed, and approved.

Write tests for the Speech to Text API before implementing the API functions so that we can use test-driven development.

Many of the Watson endpoints have optional parameters. If they are unspecified, then the server uses a default value.

When we implement a function in the SDK that maps to a Watson endpoint, should we capture these parameters using default values (model: String = en_us_broadbandModel) or optionals (model: String?)?

These files are no longer necessary and can be removed from Watson Core. They were used in the early stages of our SDK before a common network utils library or the use of AlamoFire.

Start fresh with a new project. Be sure to follow updated bundle identifier and naming conventions.

• Investigate structure of existing SDKs such as Java and Objective C
  https://github.com/AlchemyAPI/alchemyapi_android
  https://github.com/AlchemyAPI/alchemyapi_java
• Investigate endpoint urls to use in the new iOS Alchemy Language API

Many services include a number of parameters: voices, languages, dialects, etc.

How do we want to expose those parameters to clients?

Should we design enums? Or should our functions accept the same strings used in the HTTP call to Watson?

If we use strings, should our frameworks include constant definitions to enable auto-complete, or will that end up creating too much work or requiring too much maintenance to keep them up-to-date?

Documentation should be written as we go, but this issue serves as a reminder to check and revise documentation for all functions (both public and private) in the Speech to Text API.

This includes both positive and negative tests

Tokens may have an advantage over username/password authentication since they are short-lived and can be easily shared. Investigate to determine if we should continue using http basic authentication or build token-handling into WatsonAuthentication.

Similarly, most services respond with a cookie that should be set. Using the cookie can result in a faster response from the server, since it aids in authentication. We should look into receiving and setting cookies with NSURLSession.

We definitely want to implement support for (1) common use cases on mobile, and (2) all features supported by each Watson service. But do we want to expose all of these functions? Or should we just expose the functions we expect clients to call?

As an example, in SpeechToText, we have recognize() functions intended to be called by the client. They abstract the session-handling, interim results, etc. Do we want to also expose the lower-level functions that actually communicate with the Watson service?

Documentation: http://www.ibm.com/smarterplanet/us/en/ibmwatson/developercloud/doc/speech-to-text/websockets.shtml