I attended a very interesting session at the conference this year; NexGen API Roadmap. In it, our fearless leaders gathered to discuss the future of the API and perhaps the future of v14. To recap, the 3 major topics were;
1: Removing session management from the db
2: Migrating all soap calls to REST (making REST fully capable)
3: feature enhancements
I found a number of parts of the conversation interesting. To start, V14 could be a technical release, where all that is done is #1 and #2. Then, there are all the details involved with #1 and #2.
The discussion of #1 was diverse. I heard a number of developers balking at the idea of an inability to rely on tessitura to manage the session for them. But a number of others spoke up to the wisdom behind the choice. Perhaps you can read which side of the fence i'm on...
But in all seriousness, this is a big deal, and i'd like to think (for the better) that the decision has already been made. We're seeing it in Tessitura and in the world; Mobile, scalability, flexibility, TN Mobile Plus, the new touch interface. Bye bye sessions. But i encourage a debate.
Then SOAP to REST. Far less to discuss here, other than adoption rates and desire/urgency/ability to get in other feature enhancements.
Anyways, this was a great session and i thought i'd put it to the forums to see what other people wanted to say outside of the session's walls.
Thanks,James
Hi James,
My read on the session was that we were generally presented with three options in V12:
With sort of a "Pick Two" understanding. Ron didn't go into the second point in detail, but I think little is needed to appreciate its importance.
Beyond that it was floated that the development path for REST might be to ultimately:
The theory being that this would then be the job of the REST developer to implement: removing the convenient of "pre-built" functionality in favor of more flexibility for the developer. It would be important to remember, though, that so long as SOAP persists (which I'm assuming is at least another two to three years) these can't go away completely.
For my part I still feel like I need to work my way through the security considerations of the former, although I understand some of the appeal. This bleeds into my security considerations generally when it comes to having the entirety of Tessitura's client functionality ultimately available through the API. One significant piece of the SOAP API's security is simply what it can't do.
For the second, I have absolutely no desire to re-invent Tessitura's cart mechanism, but I also am not sure that having a pre-packaged cart scheme excludes also providing lower level access to transaction operations.
--Gawain
Well put, Gawain. I agree and failed to relay it as concisely as you did. Of the three, pick two.
Actually, the next thing I should say about that is the mood in the room seemed pretty unanimously for 1 and 2, unsurprisingly. But I think that there may be special pressure on IT groups throughout the network to lobby for that choice, as it may be harder for other departments in organizations to appreciate having a "featureless" version upgrade. Particularly those with investments in the feature list that was discussed at the other Roadmap session.
At least here my strategy would be to present V13, uh, I mean "Tessitura 2014", as a relief from two feature-heavy releases, including one off-cycle release. I know that the reality is that we will still be trying to reorganize ourselves around all of the new features in V12/V12.5 long after V14 is available.
That was my sentiment as well. The sooner 1 and 2 get done, the sooner we can begin to adopt / code upon the new platform; likewise, the network will have all the real tools in place to build all the features they ever dreamed. But you can't build a house on sand. You need the foundation first. A strong one, without sessions!