[Freeswitch-dev] hello and question
Steve Underwood
steveu at coppice.org
Mon May 26 20:12:22 EDT 2008
Hi,
mod_reference and mod_skel give you some code to get you started, but
they give you little clue as to what you must do in your own code. There
isn't really any documentation, at the present time, which will give you
any real guidance as to what to do. The real kicker, however, is that
until recently outsiders were not really working with these APIs, and
the naming of states, functions, etc. has been rather arcane. I reported
some basic confusion, and some of the least sane names were fixed in the
past few weeks. When I get back to cooking up my own modules, in the
next few weeks, I expect I will push for more changes to arcane names. I
also expect these will be accepted - if you don't piss off the
developers they tend to be very amenable to improvements, especially if
they might reduce support issues. :-)
Steve
Anthony Minessale wrote:
> mod_reference is quite new, I just added it because we had the first
> hint of someone new wanting to make an endpoint module in the recent
> past and I made that for him to see the basics.
>
> Since I have personally written all 8 endpoints modules in tree, there
> has not been a huge demand for docs on writing endpoint modules. If
> more people expressed an interest in coding endpoints the natural
> results would be more docs in that area. Since the majority of
> developers have done applications, that is topic we have the strongest
> docs for.
>
> If you compile a list of questions and post them or come to IRC you
> will find we can explain it quite easily and we can log the
> conversation and it can be refined into docs.
>
> On Sun, May 25, 2008 at 10:18 PM, Matthew Kaufman <matthew at matthew.at
> <mailto:matthew at matthew.at>> wrote:
>
> 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 <mailto:matthew at matthew.at>
> http://www.matthew.at
>
>
>
>
> --
> Anthony Minessale II
>
> FreeSWITCH http://www.freeswitch.org/
> ClueCon http://www.cluecon.com/
>
> AIM: anthm
> MSN:anthony_minessale at hotmail.com
> <mailto:MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
> <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org
> <mailto:sip%3A888 at conference.freeswitch.org>
> iax:guest at conference.freeswitch.org/888
> <http://iax:guest@conference.freeswitch.org/888>
> googletalk:conf+888 at conference.freeswitch.org
> <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:213-799-1400
> ------------------------------------------------------------------------
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>
More information about the Freeswitch-dev
mailing list