[Freeswitch-dev] hello and question

[Matthew Kaufman]

Anthony Minessale wrote:
> ...
> There is an example endpoint and app skel in mod_skel and mod_reference.
>
Note that mod_skel is in http://www.freeswitch.org/gettingstarted.html 
and http://wiki.freeswitch.org/wiki/Modules but mod_reference appears in 
neither. (I also hadn't stumbled across it.) It would help if it were 
referenced from the gettingstarted page, as it does appear to be very 
useful for someone in my position. Would have saved at least an hour or 
two when trying to figure out what part was endpoint-specific and what 
part was boilerplate when reading the other endpoint implementations.

> There is a header file called switch_module_interfaces.h
> http://www.freeswitch.org/docs/switch__module__interfaces_8h.html
> http://fisheye.freeswitch.org/browse/FreeSWITCH/src/include/switch_module_interfaces.h?r=8579
>
For endpoint developers, more info about what each of the IO routines 
and state handlers listed there really means would be helpful. 
mod_reference appears to address part of that requirement. I'll probably 
end up writing up something for my own use if it doesn't already exist 
in someone else's private collection, and if it seems readable I can 
contribute that.
> There is a description of the module design in this document.
> http://www.freeswitch.org/node/117
>
I'd seen that right when I first heard about FreeSWITCH. It is a great 
high-level explanation. The next more-technical level would be very 
useful to have.
> Every modules in the applications folder is a working example of all 
> the ways to use the API.
> http://fisheye.freeswitch.org/browse/FreeSWITCH/src/mod
>
That's where I started, and it works but is slower than knowing which 
handlers I need to implement and which things I'm likely to need to call 
in the other direction. Again, mod_reference appears to address some of 
this, and of course existing endpoints address this as well.
> ...
>
> Anything you are not allowed to use it not available to you.  All of 
> the objects are opaque and perhaps there are some things you can do 
> wrong but we do our best to force you into the right direction with 
> the API.
>
> There is a higher level scripting interface to the application API to 
> further simplify things if the C API is too challenging.
>
It looks very useful for application developers, not so useful for 
high-performance new kinds of endpoints, which is what I'm working on.
>
> Most functions start with the name of the header file they live in, 
> application are launched with the session that was associated with the 
> call and any function you can call on that session or the channel 
> derived from that session is probably safe though I would not 
> recommend playing with the channels states etc because that is an 
> advanced concept I would not try as my first experiment.
>
> If anyone else out there who had made some modules would care to chime 
> in on how they got started that would be nice too.
That would be helpful, for sure.

Matthew Kaufman
matthew at matthew.at
http://www.matthew.at