[Freeswitch-dev] hello and question

Anthony Minessale anthony.minessale at gmail.com
Sun May 25 21:05:05 EDT 2008

See,  That's a shame.

That is not an apology for being rude.  It's an attempt to justify being
rude which is a big difference.
I said you offended me and you chose to spend several paragraphs retorting
and then semi-apologizing in the end but with a hint of I am not wrong but
whatever I'm sorry you took it wrong......sigh. I have to tell the same
thing to my kids.  Just knock it off.
Any more like that and I will just ignore it.

You walked into our door and started complaining.  If anyone else out there
reads the original email as anything but a collection of rude comments
guaranteed to piss anyone off who has worked hard on this project, please
chime in.....

Tomorrow is the day we release 1.0.0 Three Years since the idea to make
FreeSWITCH was first hashed.
Maybe now we will have more time to make more documentation but I'm sure it
will never be enough for some people no matter how hard we try..  BTW there
is also a wiki at http://wiki.freeswitch.org with hundreds of pages of docs.

Anyway, I said I am not doing the flame war thing so Here you go:


The is the "magic link" also known as the button marked "API" on the top
menu on our homepage.

There is an example endpoint and app skel in mod_skel and mod_reference.

There is a header file called switch_module_interfaces.h

There is a description of the module design in this document.

Every modules in the applications folder is a working example of all the
ways to use the API.

Most of the functions you will need to make an Application are found in the
switch_ivr family of function namespace.
To make an endpoint you need most of the API.

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.

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.
I have written most of the ones in tree myself so I can only comment on

On Sun, May 25, 2008 at 7:31 PM, Matthew Kaufman <matthew at matthew.at> wrote:

> Anthony Minessale wrote:
>> I'll give you a heads up.  I could rant back and start a flame war with
>> you over this but I won't.
>> Plain and simple, I read this email and got instantly annoyed.
> Well, that wasn't my intent at all. Please read on for some clarification.
> (It not being my intent to start a flame war either, simply to clarify where
> I was coming from when I wrote that email late last night)
>> Especially....
>> " Speaking of which, a slightly different architecture/coding style might
>> have made the interfaces between the modules and the insides more
>> immediately clear..."
>>  There is a difference between minor critique of style (I said "slightly
> different", as you can see) and thinking that the design is bad, the
> software useless, or you a bad person. It was not my intent to personally
> offend you (or any other contributor), but simply to point out my view *as a
> new potential external developer* that, had things been designed or
> implemented slightly differently, it would have been easier *for me* *in my
> opinion* (not to be confused with the opinions of other folks who might wish
> to develop modules) for me to come up to speed.
> An example (that I did not include in my original message, which might have
> made my intent more clear) is that it is very hard to tell that
> "switch_core_session_get_channel()" is something that a module apparently
> should be calling (as I can see mod_iax.c doing, for instance) whereas
> "switch_core_timer_next()" looks to me like something used internally that
> it probably isn't useful (or might even be dangerous) for me to call. If
> there was a more clear delineation (in their naming) of which switch_*
> functions are intended to be called by certain types of modules, and which
> are intended entirely for internal use, it might be possible for a new
> developer like me to pull up a list of "these are the functions you're
> probably going to need to call to implement X type of module, and if you
> don't call them, it is likely that you've forgotten something".
> Now that's just my opinion. There might be perfectly good reasons why the
> naming is set up the way it is, or I may have even missed that there's a
> clear distinction, but not found that yet. Or there might not be any good
> reasons other than "you were the developer and you decided to do it that
> way", which is also fine, as it is your code to set the style of.
> As I said, it wasn't my intent to personally offend you but to provide an
> opening for some constructive input. I apologize for having caused such a
> reaction on your part.
>  Stick with Asterisk then, I'm sure you will much more luck........
>>  I think I've already made it clear that I think the Freeswitch
> architecture is superior, and that that's why I've even chosen to develop
> modules for this rather than something else.
>> and ....
>> "I'm doing ok, but my
>> time is very valuable and not well-spent by figuring this stuff out from
>> the source code instead of looking at the reference docs."
>> HELLO? how valuable do you think my time is sir?  I have been working day
>> and night on this project for more than two solid years and I apologize that
>> it only fits your needs "except for one thing ...." I will gladly offer you
>> a refund on what you paid for the software.
>> You have some nerve to come here and plan to make a project out of my
>> software then complain to me that it is not perfectly handed to you on a
>> silver platter....WTF?.  I do not intend to supply you with any helpful
>> information until you apologize for your rude attitude.
>>  Well, if you found it rude, than I apologize. I understand that you've
> been working hard on this software, and the reported successes of users of
> the code is a testament to that.
> It is also my opinion that the value of your software hinges heavily on
> what is contributed in the way of modules... I might be wrong, it might be
> that you and the group of folks who have been contributing so far will write
> all the modules it needs for the success you're looking for. But if I'm
> right, then listening to the opinions of new folks who show up who are
> trying to write modules might actually be of some benefit.
> Just because I find my time to be valuable does in no way diminish the
> value of yours. *My opinion* is that my time is not well-spent figuring this
> stuff out from source code. That is likely the opinion of other new folks
> who might want to develop modules. I might be wrong about that too. In my
> experience, even your time would likely be better spent if there was more
> reference documentation. That is why I suspect that it actually exists, at
> least in the form of notes somewhere, and that I simply haven't found it.
> I'm not asking to have everything handed to me on a silver platter. I'm
> asking for pointers to what does exist that I might have missed, and
> providing my opinion as a newcomer that developing modules could be easier
> (at least given the documentation I've managed to find so far)... and my
> opinion that if it were, maybe there'd be more contributed modules... which
> I think would be a good thing for your project.
>  To summarize I do not owe you anything, you can learn how it works and
>> write the missing documentation as a repayment for the software being open
>> and free for you to use if you wish.  Or you can come to IRC (once you have
>> publicly apologized) and lots of people including me would be happy to point
>> you in the right direction.
>>  You are right, I do not owe you anything. And I apologize if you think
> that's what I claimed, because I've never thought that. I do plan to learn
> how it works, even if there is nobody who wants to point me at existing
> documentation, or even if there is no existing documentation. If that is the
> case, it will take longer for my module to be written and make it less
> likely that it will interoperate properly with the core code. That will be
> my problem, of course, but *my opinion* is that it will also be the
> experience of other module developers... maybe scare them off entirely. And
> if that happens, the total collection of Freeswitch and its modules will be
> less valuable than it might be otherwise. Which, again, is *simply my
> opinion*. Perhaps it would instead be better if a small core group of
> committed developers writes them all, and those of us with our own crazy
> ideas never have our modules see the light of day... you never know.
> Matthew Kaufman
> 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 <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20080525/4f8f0534/attachment-0001.html 

More information about the Freeswitch-dev mailing list