Page Comparison

...

...

• Roll call
• Minuet update:
  • Nothing to report
• Action items:
  • Rob: will send Github identifiers this morning
  • Peter: provided Symphony client binary to Nick
  • Nick: received it, and was able to run Symphony inside OpenFin as a webapp. I was able to embed the app-bridge API into the window, via OpenFin extensions, but everything breaks.  The webapp thinks it's in Minuet and all sorts of stuff blows up.  I don't have a handle on what or why.  I tried stubbing out the API, but that didn't really get me anywhere.  Since I'm using live Symphony which is all obfuscated code it's going to take me some time to figure out.  It would be great to chat with the Electron POC folks to see if they have any pointers or paths to follow.
  • James: Rob may know why things blow up when the app-bridge is instantiated
  • Rob: I don't, but I know the people who do
  • Nick: it looks like Symphony is trying to call Minuet APIs that aren't in app-bridge - it detects the app-bridge, then assumes it's in Minuet
  • James: that's very interesting information, and if Symphony is using Minuet APIs directly then that's good to know
  • Nick: there are also a number of APIs in app-bridge that return objects and I don't know the structures of those objects
  • James: do you only have the obfuscated code?
  • Nick: I have app-bridge code, but the Symphony code is obfuscated.  If I get to that point I could possibly reverse engineer it.
  • James: it's an interesting question because our assumption going in was that the app-bridge was sufficient definition of the interface, but if there's Symphony client code that needs to be open sourced, then there's an interesting question there about whether we need Symphony to look at those bits of code and decide what their public container interface looks like.
  • Nick: to give you an example there's a method in app-bridge called "get client info request" that internally calls SystemInfo.getSystemInfo.  I don't know what that system info object looks like, and in the OpenFin environment that object is going to be different, and I assume I'll have to convert it to what Symphony expects.  What's inside that Symphony object is a black box to me at this point.
  • James: so Rob, as a Symphony representative, this sounds like something we need to have a more in-depth conversation with Symphony about, if we want to make Symphony less dependent on Minuet
  • Rob: there's a bit of an effort to define this clearly, but this gets to what every technical mind has been thinking about this - that we need to be defining a slow-moving, well-defined, well-documented interface between Symphony and the container.  My next steps are two-fold:
    • Tactical: get to the bottom of this problem of having some semblance of an interface, but then we're circumventing it
    • Strategically: bring the right type of skills to this meeting going forward so we can have the right people in the conversation
  • James: this sounds like progress.  I'm also having a little trouble finding the right person to sign our contribution contract.  Our guy has had a look and thinks it'll be straight forward, so I'm hopeful we'll be able to sign up and immediately show progress.
  • Nick: ideally if there's something working in Electron that's further along, I could work from that.  That would be a lot easier than working from live Symphony code.
  • James: if we can actually get everyone working together on the POC, then we can figure out the best path forward.
• WG Charter (James):
  • In this week's ESCo status update, one of the things that came out is whether we should be adjusting / splitting what this WG works on.  We've been working for 7 to 8 months and we still don't have Minuet code, so the WG charter objective of managing Minuet code is rather a moot point.  Peter had suggested that actually if we do ever get the Minuet source code that the management of it might be more suited to a project than a working group, and that maybe the WG should be focused on the standardisation work.  Other people on the ESCo were talking about the API to integrate into Minuet and Symphony, so we felt it was an opportune moment (though given the attendance today, perhaps not as opportune as I hoped) whether we should continue with what we're doing, whether we want to create a new WG, or discontinue this WG, or ...?  I'd be very interested in your thoughts.
  • Nick: I'd love to talk about container interoperability standards.  That, to me, would be a richer, more valuable use of time within the WG, and that could go a long way to creating standards that are supported across the industry as they move to HTML5 containers.  It's an area where organisations are developing multiple containers within an org without standards, which creates a huge drag on productivity.  I think this'd be well served by the Foundation.  Looking at the app-bridge code itself, it seems very specific and not the way you'd want to organise a browser standards-based API (e.g. APIs like "play chime", "show alert settings", "get/set temp value").  These things seem very Symphony specific.  It's not a criticism of the code, it's code that's focused on building Symphony, not any application on a container.
  • Rob: that's what I was mentioning before - we have some semblance of this now, but the next piece is talking about what is optional / required / configurable.  This is the difference between tactical "get it working", vs strategic "make this a real product" which lets companies fight it out regarding what's supported vs not-supported in the real world.
  • James: so it sounds to me like we double down on the standardisation effort.  The POC was to bring out the practical side of that.  It's probably a combination of identifying what the requirements are, the collection of W3C standards for basic things and calling that done & dusted, and then for the more interesting things that don't have standards, talking about those in more detail.
  • Nick: I think that would be a great approach to take. Trying to align this with what W3C is doing makes all the sense in the world.  No point in creating APIs that already exist in Chromium or APIs that are emerging in Chromium.  Everything is going in this direction, more or less.
  • James: different aspects of packaged applications that different vendors have done.  There's plenty of prior art, I guess I'd say.  My experience in this WG is that it's hard to get actual real work done by anybody.
  • Rob: I agree.  It's 60 minutes of talking on the call, with the exception of the POCs.  But breaking off and doing things between meetings would be ideal.
  • James: it's been a struggle.  We've asked for things and people have said they'll do things, then they don't.  Which is part of the reason we've been addressing the...
  • Nick: let's say we put together a straw man, how do we influence Symphony?
  • James: that's been challenging.  When there's an enlightened alignment, it's less of a problem.  I've heard from several people in the LLC that this is what they want, what their board members want.  I think if we came up with a standard and had a credible story about how we'd take this through a standards body, then I think we'd have a good argument to get this in the work plan for the LLC.  Obviously there's no promise, but you've heard from members here (and I've heard from other LLC staff) that it would appear that Symphony being able to be deployed on multiple container is a goal, perhaps a lower priority goal, but a goal.
  • Rob: on the technical side things are totally aligned.  We want a future where that can be the case.  If this WG can help move this forward then it will land on the LLC side.  The intent is aligned, especially now that Minuet is less interesting.  Having a strong story is very much desired, so we will get resources & bandwidth at some point (within the usual constraints of startup prioritisation).
  • James: so that's the best we can do Nick.  If we can show that we're making some progress and the banks are aligned then my guess is that if we make some noise about a standard that's well thought through then there will be interest from other container providers.
  • Nick: yeah I'd imagine.
  • Peter: and if/when Minuet lands (laughter) then it can be punted to a project team, to minimise distraction to the core standardisation focus of this WG.
  • James: yes, though we'd want to influence the open source Minuet project.
  • Peter: true, and they can choose to ignore those recommendations, at their own peril.  
  • Nick: that's how W3C works
  • James: this is really good feedback and I'll reflect that back to the ESCo.  Despite it being a bit moot, what do people think of Minuet being a project?  I can see how that might be more aligned with day-to-day decisions of this group.
  • Tim: I think we cross that bridge when we come to it.  Minuet isn't really a thing right now, is it.  Another question: is the Minuet code being updated to track the work of the LLC?
  • James: GS was ahead, there was a merge that might have brought LLC codebase up to date. Rob?
  • Rob: we've mostly been doing bug fixes to support WebRTC plugins.  Not sure what the latest is, but the last merge was a while ago.
  • Tim: I want to play with Minuet.    We're just not there.
  • James: the feedback I'm hearing here is to focus on standardisation.  I don't think the POC work is a complete distraction - it's an interesting piece of work.  But it's not the be-all / end-all of thew the standardisation work.  There's also the abstract work.  Nick - your organisation is probably the furthest forward in thinking about this, given the nature of the commercial world you live in?
  • Nick: yes
  • James: concretely, what do we see as the next step on the more abstract view?  Base requirements (e.g. notifications - is the W3C API sufficient?) then concrete additional requirements?
  • Nick: on the OpenFin side we have our own notification API, partly for historical reasons, partly because it can do more than the HTML5 notification API (e.g. styling of notifications).  It would be interesting to look at whether these features meet the needs of what people want to do with apps.  You could look at similar / dissimilar approaches to other system level controls, like in the Electron APIs you can create system-level toolbars (with native look-and-feel).  We've not done that stuff yet, our feeling is that when youryou'e re building this kind of desktop hybrid app you really want to create your own look-and-feel for those kinds of items like menu bars, toolbars, etc. and you want those things to be styled according to the branding of your app, and not left up to the OS to do.  That OS stuff is generally a leftover from desktop apps and we want to move away from it - the HTML5 model gives people more power and freedom.  These are interesting conversations to have.  Realistically both models could be supported.  Another interesting point is whether we want to create write-once/run-anywhere apps, then we need the interface for this API to support both running in a commercial browser and running in a desktop.  And that's an interesting point because you can't necessarily create this using a decorator API.  So that's when you look at something more message or event based that could be interpreted by either a JavaScript container within a browser or it could be interpreted by a hybrid desktop application.  I have some things I can probably share with the group.
  • James: that'd be useful.  Let's take that as a kickoff - to set some context.  I'll try to lay out what those steps will be too.  Any other thoughts?  I'm enthused by this standardisation focus.  We may also want to rename the working group?
  • Peter: on a super-tactical front, perhaps the next step is to revise the charter, and perhaps rename the group at the same time?
  • James: yes, but given attendance at this meeting I'd want to socialise this with the broader group first.
• AOB
  
  • <none>

...