[erlang-questions] What should go into the FFI chapter of the book

[Joel Reymont]

Serge,

I agree with you on everything you wrote below. This is just the kind  
of feedback I love.

I have also been told that there's work on WxWidgets as a linked-in  
driver.

My focus is to both finish the book quickly and to keep it  
informative. This requires a compromise and I suspect that the book  
will not look like anything I envisioned in the beginning.

It may well be that it's better to either describe the WxWidgets  
driver than to write a Cocoa bridge for the book. Describing existing  
code takes far less time than writing significant new code bases.  
WxWidgets is also cross-platform so Windows and Linux users of Erlang  
could run it, unlike the Cocoa bridge.

In the end it may well suffice for me to just elaborate on what you  
listed below. There's more than enough content, complexity and value  
in doing this. I think I'll try to start down this path and see what  
happens.

	Thanks, Joel

On Dec 11, 2007, at 1:04 PM, Serge Aleynikov wrote:

> I think it would be useful to cover link-in drivers from the  
> following perspective:
>
> 1. C types: ErlDrvData, ErlDrvBinary, ErlIOVec, etc. and how to  
> marshal terms to Erlang using these primitives.
> 2. Taking advantage of driver queues.
> 3. Monitoring health of Pids from C, and performing driver shutdown  
> or resource cleanup when a Pid dies.
> 4. Highlighting differences between output methods (output, output2,  
> outputv).
> 5. Handling events from other sources (driver_select, ready_input,  
> ready_output and event callbacks) in the driver.
> 6. When to use ei and when not to.
>
> At least there is currently no in-depth illustrated coverage of  
> these subjects and one has to go through a broad trial-and-error  
> cycle (at least I know I did :-( ) that keeps the learning curve  
> pretty steep before he/she learns these concepts and the mysterious  
> veil of driver complexity dissolves.
>
> Serge

--
http://wagerlabs.com