Table of Contents

Date

09 Feb 2017

Attendees

Actions items from previous meetings

• Peter Monks: check that everyone received the meeting invitation
• Former user (Deleted): identify suitable LLC engineer to work with Former user (Deleted) on REST API standards, and notify the group
• Peter Monks: document the decision to cc the mailing list on all comms (even those specific to a particular sub-group) on the wiki
• Former user (Deleted): create Confluence page for "REST API Standards" sub-group (under Working Group Documents) and populate with proposed:
  
  • Scope
  • Collaborators
  • Deliverable(s)
  • Timeline
• Johan Sandersson: populate existing Confluence page for "Use Cases" sub-group with proposed:
  
  • Scope
  • Collaborators
  • Deliverable(s)
  • Timeline
• Peter Monks: add standing items to future agendas for status updates on the sub-groups

Agenda

Meeting notes

• Introduction
  • Anthony Fabbricino: Agenda is to go through 3 breakout areas where people volunteered to lead, we’ll ask for an update. As they do, if there are people on the call who want to indicate they’d like to join those groups, we’ll move those forward. I’m on the API standards, Johan on Use Cases, Paul Tessyier on language bindings. Johan’s done the most work. I think Malay was going to join in his place. Is he on?
  • Aaron Williamson: not yet.
  • AF: Peter, can you give an update?
  • Peter Monks: Not really.
• REST API standards update
  • AF: The next area we talked about was documentation of best practices for APIs. What I’ve done so far is pull two starting resources: the guidelines from the LLC that Bruce authored and the REST guidelines provided by BNY Mellon. I haven’t had time to integrate the two so I don’t have much of an update. Does anyone on the call want to help me work on that? This is a good time to expand upon these breakout groups.
  • Dov Katz: I’d love to be involved but can’t commit the time, but may have others internally who can represent MS on some of the groups.
  • AF: That’s fine—it’s not so much the authoring part, it’s initially an editorial review that I’d like, to get more POVs on the document. I’d welcome MS’s participation. I’ll reach out separately about setting up that discussion. Anybody else have any other work items to raise?
• Language bindings update
  • AF: Ok, and the third breakout area is language bindings. But without Paul here, there’s no update there. I’ll open the floor for any other areas of discussion.
• REST API implementation discussion
  • DK: I’ve had some conversations, sharing my experience with the Java API, but there’s obviously two APIs – the generated swagger API, and the Java REST API. I don’t know which direction this WG wants to go as far as the combination between the wrapper & Java API, but as a consumer I’ve run into issues and would like to hear what others’ experience is.
  • AF: There are client-side and server-side use issues. What we’re trying to do w/REST is focus on server-side. And we have some client-side implementation around the Desktop Wrapper API—Paul’s trying to improve the language bindings to provide consistency in dev experience.
  • DK: A common issue is that I’ll start with Java API, realize what I want isn’t there, then have to generate a separate one to use alongside it. Wondering what the direction is for combining the two.
  • PM: I think Frank’s in the process of splitting the raw swagger API from the hand-rolled code he’s written on top of that, which makes it easier people to decide which level to operate at – raw swagger objects or higher-level listeners, etc. DK: I suggest you ask Frank to present to the group on his roadmap.
  • DK: Yes, would love to see that, don’t want to duplicate effort.
  • PM: We could end up with two value-added implementations on top of the raw swagger, I think that would be fine.
  • DK: What we’ve seen is that Frank’s work on the API is tailored to his specific needs rather than providing access to all of the interfaces we need.
  • PM: That may be because Symphony has influenced Frank away from providing some interfaces that it believes are not supportable.
  • DK: I would love to hear about Frank’s roadmap and to have a place where people can share recipes for what they’re doing with the Java API.
  • PM: The Symphony Java Sample Bots project is run by myself and Mao—if you want to put samples there, we’d love that.
  • DK: I could share neutral code I’ve developed there, although I don’t think MS allows access to Github. Happy to walk people through journey I’ve taken to get to random bots.
  • PM: Malay, I see you’ve joined the call. Matt Joyce sent his apologies. FactSet are the project owners of the .NET REST client, Matt owns the new Python client. Maybe there’s a subgroup around consistency between these efforts, including Frank’s. This group could provide feedback on roadmaps for purposes of aligning them.
  • Malay Shah: That’s a great idea, would love to see concepts come together around building on top of swagger API across languages so they feel familiar.
• Use Cases update
  • AF: Malay, we went through updates on breakout groups and I know Johan put a couple things on the wiki around uses cases. Can you give an update on what he’s done and wants to do, so others can volunteer to join if they’re interested?
  • MS: I don’t have much of an update. He’s been working on use cases. I don’t know if he’s shared it yet, but next step is to define how much detail we’re looking for and what the structure is. I can ask him to send out an example or two and we can discuss over email what we want that to look like.
  • AF: Is the work he’s done public on the wiki?
  • PM: It should be available on the wiki and visible to everyone on this group.
• Conclusion
  • AF: Thanks Malay for the update. Any other topics before we adjourn? Action around brining Frank into the next meeting.

Action items