add minutes from 2015-11-19 meeting

wg-meetings/2015-11-19.md

@@ -0,0 +1,169 @@
+November 19th 2015 - Node.js API WG Meeting
+================================================================================
+
+* [YouTube recording](https://www.youtube.com/watch?v=3rszjGYpbyM)
+* [Hangouts Event](https://plus.google.com/events/cv3h505lip7aqvil4n5ri0kl8e8)
+* [issue for this meeting](https://github.com/nodejs/api/issues/11)
+* [previous meeting](https://github.com/nodejs/api/blob/master/wg-meetings/2015-10-23.md) - 2015-10-23
+
+
+Attendees
+================================================================================
+
+* @pmuellr - Patrick Mueller (NodeSource)
+* @mhdawson - Michael Dawson (IBM)
+* @orangemocha - Alexis Campailla (Microsoft)
+* @obastemur - Oguz Bastemur (JxCore)
+* @Qard - Stephen Belanger (AppNeta)
+* @stefanmb - Stefan Budeanu (IBM)
+* @trevnorris - Trevor Norris (NodeSource)
+* @robpaveza - Rob Paveza (Microsoft)
+
+
+Agenda
+================================================================================
+
+* Oguz B - I hope the second meeting focuses on public API more. It would not
+  make API work separating from node.js entirely.
+
+* Oguz B - AFAIK, JXcore's public API is the only proven approach available ATM
+  and it works. IMHO a public API work shouldn't take much time. Cons/Pros etc. discuss and decide ? (Attention: node-ch and JXcore macro are private API!)
+
+* https://github.com/nodejs/api/issues/10 - Native modules API:
+  the FFI approach - Alexis C
+
+* next steps - stand-alone chunks to iterate on - what are they?
+  * datatypes? https://github.com/nodejs/api/blob/master/native/data_types.md
+  * prototype building API on lower-level API (js || native)?
+
+
+Minutes
+================================================================================
+
+
+Public and Private APIs
+--------------------------------------------------------------------------------
+
+[YouTube 3:56](https://youtu.be/3rszjGYpbyM?t=236)
+
+Oguz:
+
+General priorities:  
+
+1. private - reduce amount of work between native bits using shims
+2. public - native add-ons; nan as an example
+
+Public API could have it's own types
+
+Patrick: we need some concrete issues
+
+Michael: What APIs are we talking about - the API we provide to modules?
+
+Oguz: yes
+
+Michael: need a full definition
+
+Patrick: different forms of "definition"; C code, documentation, API
+modelling languages, ...
+
+Michael: Oguz's current one is in C?
+
+Oguz: current JxCore API isn't appropriate for public API
+
+Rob: current API is V8; we should audit common modules to figure out what APIs
+we need
+
+Trevor: still limitations; special VM APIs like GC notification
+
+Patrick: maybe 80/20 is good enough for now
+
+Trevor: how would this be "blessed", and if it has a performance impact, will
+never be blessed
+
+Rob: should AIM to be macros and templates aimed at V8, so no performance impact;
+other impls might need to add C code
+
+Patrick: let's create an issue for this
+
+Oguz: 60% of this will be easy
+
+Trevor: this approach is the most complicated way to get anything done; need to
+also get the all the existing modules converted
+
+Rob: no existing modules are going to work with a new API anyway
+
+Trevor: it's getting complicated; now we need to support multiple APIs
+
+Oguz: SQLite is probably a good example of types of APIs external modules need
+
+Patrick: we need an issue
+
+Trevor: does other native headers (Chakra) exist in V8?  Do we ship multiple
+versions of node?
+
+Rob: no other native headers; runtimes act like drivers
+
+Patrick: we need an issue
+
+Rob: I volunteer *[pjm: not his exact words :-) ]*
+
+Trevor: more actionable if consolidate we node header into a single header;
+one official header; also create a user-facing shim for V8, not specifically
+targeted for abstraction, just to get started
+
+Patrick: what does the user-facing library look like?
+
+Trevor/Michael/Rob: like nan, more API and ABI stable than nan, but can never be
+100% API and especially ABI stable, and can be included in node core.  For
+native module authors.  Eventually use that API to abstract over multiple JS
+implementations.
+
+Patrick: I think we're talking about two main issues: abstracting JS engines and
+API for module authors.  Same problem space, attacking from different ends.
+Let's get some issues created.
+
+
+FFI
+--------------------------------------------------------------------------------
+
+[YouTube 38:44](https://youtu.be/3rszjGYpbyM?t=2324)
+
+Alexis - FFI is invoking C functions from JS, most native modules could use
+this to do their work.  Some issues have come up regarding performance issues,
+but there are some approaches which minimize impact on performance, such as
+using templates and having a compiler provide some glue, as suggested at
+https://github.com/nodejs/nan/issues/349#issuecomment-110569177
+
+Patrick - there are some issues in node regarding getting Nate's FFI code into
+core.
+
+Trevor - PR for FFI was already rejected as it touched too many internal things;
+also it needs to be a separate module so that it can be removed by someone who
+doesn't want it on their system (for security/safety reasons).
+
+Michael - what does FFI solve
+
+Rob/Alexis/Michael - Also need to handle calling from native code back into
+JavaScript.
+
+Trevor/Patrick - Buffers as os memory; adds methods to Buffers; implies constraint
+that Buffers are allocated in memory and never moved; perhaps we need
+a separate thing from Buffer.
+
+
+wrap-up
+--------------------------------------------------------------------------------
+
+[YouTube 52:09](https://youtu.be/3rszjGYpbyM?t=3129)
+
+Patrick:
+
+* create some minutes, issues to focus on particular subjects
+
+  * JS engine abstraction API
+  * native module API for non-core modules
+  * moving FFI forward
+
+* next meeting? In January?  No nays.
+
+* create issue/doodle/gdoc for next meeting in a new issue