Original proposal:
- Direct
- Indirect
- middleware
- library interposition
Sean Ziegeler proposal:
- dedicated, internal
- dedicated, external API (catalyst, libsim)
- multi-purpose, external API (ADIOS, Glean)
- external interception (interposition), LD_PRELOAD
- external inspection (Fogal)
Joseph Cottam proposal (all names are provisional):
- Explicit: The sim knows that there is a vis. The vis knows that there is a sim. This may be sim makes API calls to some visualization or some custom-coded vis.
- Permissive: The vis knows there is something, but isn't necessarily sure what is there. ADIOS fits this.
- Clandestine: The sim does not know there is a vis. LD_PRELOAD or source code instrumentation (like how Tau uses PDT) fit in this category or MPI-IO call intercepts.
Hank's attempt:
- Embedded / bespoke / tailor-made / custom / compiled in
- API
- Dedicated (Catalyst, libsim)
- General (ADIOS, Glean)
- "Clandestine" ("transparent"? "oblivious"? "concealed"?) (How about "invisible"?)
Group attempt:
- application-aware
- bespoke
- dedicated API (Catalyst, libsim)
- multi-purpose API (ADIOS, Glean)
- application-unaware
Concern brought up at end: bespoke / dedicated / multi-purpose are points along a spectrum of methodology for application-aware integration. The concern is that interposition vs. inspection wasn't a change in methodology but rather more of a change in 'how' the system achieves an end. Tom F. argued that inspection offers considerably more in terms of expressibility, able to realize a much wider breadth of in situ approaches than interposition (succinctly: one can implement interposition-style in situ with inspection, but inspection-level control with interposition is impossible), and so this change is more than just an implementation detail.
