Versions Compared

Old Version 8

changes.mady.by.user Peter Monks

Saved on

compared with

New Version Current

changes.mady.by.user Peter Monks

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

...

    • What we were going to do with Minuet wasn't very clear from the beginning . There were different view points.  Some of the GS folks thought that it was to promote Minuet as a competitor to Electron or any of the open source containers - they were quite vocal about that in the beginning.  Some of the other participants however were a lot more interested in the standardisation.  As the year wore on, it's become clearer that the LLC isn't particularly interested in Minuet per se as a topic.  Without the open source contribution and with a difficult situation regarding people with different views, the enthusiasm for teams to do real work is low - people are happy to turn up and talk at the meetings, but when it comes to real work nothing happens.  For example some time back I asked people to share their existing analyses of containers, and there was lot of "yeah we've got that and would be happy share", but then nothing was shared.
    • On a red / amber / green scale, I'd say Minuet stewardship is red.
    • Q&A:
      • Lawrence: I agree on the colour status.  When I think about Minuet from an LLC perspective, when we entered into using Minuet we were looking at it as a solid basic container that would be open sourced and we'd build a community around it and get things up and running.  Looking back there are questions technically around Minuet, like how to provide it on a Mac desktop, and I think there's an issue with the level of contribution to Minuet, especially given the delay in contribution.  Of course we don't have a community around it since we don't have the code.  Looking forward, to reset or re-baseline it is a good idea because where we were art the beginning the year vs where we are now I wonder how far we're going to get even if we do get Minuet eventually.
      • James: I completely concur.  In fact as I was writing this, I was thinking this needs a reboot.
      • Lawrence: the LLC is very interested in the topic of containers, but our level of confidence around what we'll be able to do with Minuet... ...well it hasn't been a good year.  It's not that it isn't important, but the idea of bootstrapping a new container and standards around it is a good direction to go.  The other question I have is that the point of these WGs is focused around code contributions.  Can we get the participants to contribute?  It's been a bit moot given the lack of Minuet contribution, but...
      • James: my honest answer is "no".  The initial answer was "yeah great idea to get Symphony running on Electron", but no one's stood up to do the work. My experience in these kinds of WGs elsewhere is that the banks are happy to rock up and give an opinion, but they're not happy to do work.  It ends up being the vendors who do the work.
      • Frank: it's funny that Markit are not participating in it.  We put Tim Burcham on the group and his focus was on the adaptability of applications & modules on the container, and how we'd open source it in the end.  Perhaps the focus on the container is too narrow?  Perhaps focusing on how applications can adapt to different containers is more...
      • Lawrence: is that a container thing or an API thing?
      • Frank: it's more on the API but there's some visual components. Have you considered the implementation of a UI component?  Or is it focused on API interactions with the Symphony back end?  I see this WG as being about more than just the container - it's how applications can get...
      • James: in fact one of the problems was calling it the "Desktop Wrapper WG" from the get go, while not defining either term.  When I first started I couldn't tell if it was about the container or the APIs.
      • Lawrence: it's interesting that the desktop API was different early on.  We've renamed them twice.
      • Frank: my recommendation would be to revisit the charter of this group.  And change the "desktop" and "APIs" - I'm not saying we merge it with the API WG that Anthony is working on, but more the "extensions API".
      • Lawrence: it's an interesting question around how you decompose this.  How do you integrate the UI elements and speak to the UI elements.  They're all rendered in HTML, so when you talk about the user visible constructs, are they components of the API or are they aspects of which HTML widget libraries do you use in the HTML front end code, whether it's API related or not?  Are you talking about an API or an HTML coding standard?  I don't mean to complicate it, but I think it's a really good idea to try to figure out where these things should live.
      • James: it's an ontology question, and would also help with Anthony's WG.  If we're going to have WGs around Symphony, perhaps ESCo needs to define an ontology of WGs, both of the current ones and future ones.
      • Frank: Markit sponsors our own API/UI module framework and we want to layer it onto Symphony APIs.  That project involves some of the Symphony APIs and some of the F2 framework.  We've written a shim between the F2 framework and the extension API that Symphony provides.  That code that we've created, Javascript code, is something we'd want to contribute to the Foundation, and it relates to interoperability between an existing framework (F2) and Symphony.
      • Lawrence: sounds like an API binding.  Apologies I have to drop off.  Happy to sync up offline.
      • James: with respect to the Desktop Wrapper WG, or whatever we call it, we should table this to next WG meeting.  I'll bring up in tomorrow's meeting and see what the WG members have to say.
      • Peter: this might also relate to the existing agenda item regarding Minuet stewardship as a project, rather than a WG.

Action items