Meeting 18th May 2015 12:00-14:00

[CRoebuck]

COSTEC ? Go on. I'll bite......??

Agreed,  5000 VI framework is not going to be fun to work with

[drjdpowell]

I was thinking more of just the QMH part, rather than the whole framework.  JKI state machine v. NI QMH template.

[MikaelH]

FYI, if you look at the JKI State Machine, try the UML tool's function "View VI in UML state digram..." 😉

http://www.youtube.com/watch?v=VncaD_pKe_s

[CRoebuck]

Ah, so your framework extends beyond the QMH, I misunderstood

How about a three way comparison, JKI SM v's NI QMH v's DQMH perhaps (seeing as ours is an extension of NI's QMH and JKI's Private Events Template)

[swatts]

I'll step back and let you chaps sort the details. It's going to be a packed agenda I think, maybe we should declare a 3rd hour!

[CRoebuck]

That's not a bad idea (3rd hour !!!)

James, what's your thoughts ?

[drjdpowell]

CRoebuck wrote:

Ah, so your framework extends beyond the QMH, I misunderstood

How about a three way comparison, JKI SM v's NI QMH v's DQMH perhaps (seeing as ours is an extension of NI's QMH and JKI's Private Events Template)

There are two independent comparisons, really.  The communication framework of "actors" and the QMH used to implement an actor.  I could easily adapt the NI QMH into an actor in my framework, and you could use the JKI SM with JKI-style Events (as, indeed, JKI must be doing, yes?).

So, discussion points could be:

-- Differences between JKI SM and NI QMH (and I would argue strongly that the NI QMH is flawed)

-- Similarities in how you make either into an actor (I saw a recording of your 7x7 CLA presentation and was struck by the familiarity)

-- Differences between the weak-typed, text-variant-style messages of my system and the strong-typed cluster of User Events used in the JKI Public/Private Events framework.

-- James

PS I could do a third hour.

[PNHorn]

We could judge them by the Emery's scale. Phrase coined by Jack Dunaway at eCLA.

[swatts]

I really liked that!, in the reverse of my original plan (which was just to take the inherent framework complexity and factor it out until we had a number for the problem solving bit). Having a number for this factor is an indication of the possible complications vs complexity for the framework. I think the only thing missing is another metric for adding a requirement and then getting the number again, this would also give a scaleability metric.

Pats on the back to all of us BTW, I think any of the subjects of our presentations in isolation were something to be proud of but the quality of all of them en-masse was just great!

[PNHorn]

If there's time on the 20th, I'd like to do a quick update on the Assert API, as I've made some pretty big changes to it based on feedback from the CLA Summit. I'd only need a few minutes.