On Thu, 2008-04-03 at 11:28 -0400, Ward Mundy wrote:
> 1. Thanks for your note. How much of it, if any, would you be willing for me
> to publish? You've made some good points.

Feel free to publish as much or as little as you'd like.  I'd only ask
that if you do publish snippets of the conversation (say as part of a
follow-up article), that you also link to the entire conversation, so
that people can read my comments in their full context.

> 2. Just to clarify, even though I copied Philippe on my original note to
> you, that was for his information only. He knew nothing of the article and
> had no input into it. I was not dragging FreePBX into the argument.

Fair enough.  Philippe told me the same thing.

> This isn't a case of adding a bigger engine so that the starter motor
> has to be relocated in a vehicle. The car still runs the same way! It's more
> akin to building a car with an engine that runs on kerosene and wondering
> why all the people that depend upon gasoline are upset even though you don't
> sell gasoline. As I said: "You Break It, You Fix It. I Break It, I Fix It."
> Pretty simple concept really... but one that even good software developers
> sometimes overlook.

Ward, I don't know how else to say this.  Yes, the engine runs the same
way, but it's not the same engine.  The changes weren't made by devious
Digium overlords deciding to break everyone's third-party applications.
We have never and probably will never guarantee source-code level API
guarantee between major releases, and I think your expectation that we
should is totally unrealistic.  Would you expect Windows 3.1 drivers to
work for Windows 98?  Of course not!  Why?  Because the Windows driver
APIs changed.  

Changes *were* made to make Asterisk more robust, and as a side-effect,
some people will have to make minor changes to their code to get it to
work with Asterisk 1.6.

Let me give you a simple example from the Asterisk source code.  In
fact, let's talk about the very function that you mentioned in your bug
report -- the ast_config_load function.

In Asterisk 1.4, the ast_config_load function took a single parameter...
the name of the configuration file to load.  For Asterisk 1.6, that
function has been changed to take a second parameter, which is a flag
called CONFIG_FLAG_FILEUNCHANGED.  If set, this flag tells Asterisk to
check the file modification time and return a particular value if the
modification time is the same as the last time that Asterisk read the
file, thus allowing Asterisk to be more efficient in its file parsing.

Now, if you don't want to use that flag, you can simply change the code
that used to say:

myconfig = ast_config_load("blah.conf");

to instead create a new struct with our flag options (empty in this case):

struct ast_flags config_flags = { 0 };

and then simply reference that struct in the 

myconfig = ast_config_load("blah.conf",config_flags);

See, that wasn't so bad, was it?  It's not as dramatic of a change as
your article (and your analog of changing from kerosene to gasoline)
would imply.  Any programmer worth his salt would be able to update that
in almost no time at all.  (Shoot... I'm not a developer and it only
took me less than ten minutes to find where ast_config_load was defined,
figure out what had changed, try to remember how to define a struct,
test it out, and write up this explanation.)

Now I'm not sure this is the only change that affects app_swift, but in
a way, it makes me chuckle... all this brew-ha-ha over two little lines?
In a way, I'm glad this has happened so that we have a chance to discuss
what's happened, and make sure that we handle things in a more
responsible manner next time.  Anyway, feel free to ask me (or any of
the real developers) if there are other API changes you'd like
explained.

> 4. Re: "I realize you're not a software developer..." That's a good one. I'd
> be the first to admit that I'm not the sharpest tool in the shed. 

I think you've read too much into this... I didn't say that to belittle
you in any way, shape, or form.  I only said that because that's the
first thing you told me when I met you.  Please believe me when I say
that I'm not trying to be antagonistic at all here.  Even though I've
done a fair amount of programming in my (albiet short) career, I
wouldn't consider myself a developer either.  I simply said that so that
you knew that I wasn't trying to bombard you with technical developer
terms.

> 5. I, too, was a little surprised to receive a message from Cepstral
> advising me that a Digium official told him that we may be in violation of
> the GPL license by publishing our PBX in a Flash ISO. As you put it, I would
> have preferred that Digium share its concerns with me privately. 

I wasn't present in the meeting betweens between Cepstral and Digium
over the past little while, but from what I understand of the situation,
Digium wasn't mentioning anything specifically about PBX-in-a-Flash.
The discussion was simply "Can someone distribute a module that links
against the proprietary Cepstral code?"  As far as I know,
PBX-in-a-Flash wasn't specifically mentioned.

> All of those reported allegations were based upon incorrect assumptions
> about the contents of our distribution as I have since told you, but no one
> ever clarified the situation to the Cepstral folks. It's kinda like trying
> to unring a bell. So, yes, communication is a two-way street.

I can't speak for anyone else's allegations or assumptions, but I can
say that if I had been present in the meetings and had a concern about
your conduct, I'd would have let you know personally and privately.  I
agree one-hundred percent that communication is a two-way street.  All I
can do is give you my word that I'll do my best to communicate any
concerns I have with you, and hope you'll extend me the same courtesy.

-- 
Jared Smith
Community Relations Manager
Digium, Inc.