[asterisk-dev] [svn-commits] tilghman: trunk r86065-/trunk/apps/app_meetme.c

[Tilghman Lesher]

On Wednesday 17 October 2007 15:32:02 Dan Austin wrote:
> Tilghman wrote:
> >> I can provide a patch to CHANGES if a Mantis admin will re-open
> >> 9609.
> >
> > Reopened.
>
> Thanks.  I've uploaded a small patch to CHANGES.  In keeping
> with the existing notes, the new entry is only a brief summary.
> I can make it more verbose if needed.
>
> If I may, I'd like to get some feedback about the pros/cons
> of part of the original patch that included the ability to
> configure the column names.  I understand the response in
> 9609 with regards to Asterisk 'owning' the table and that
> the column names in the database should match the hard-coded
> values in app_meetme.  The issue is that this patch/feature
> allows app_meetme to directly support the scheduling
> provided by the Web-MeetMe suite.
>
> As I mentioned in on Mantis, I can write an upgrade script to
> be included in the next release of Web-MeetMe to rename the
> columns in existing installations.  That would mean a hot-cut
> for upgrades from the existing Web-MeetMe installs to the
> new version.  I suspect that many of the existing setups
> are using a version of MySQL that does not support views, so
> renaming the columns and breaking backwards compatibility is
> the only option unless we can include the ability to configure
> the column names in app_meetme.
>
> The code to make the column names configurable is trivial, and
> defaults to setting the column names to the current hard-coded
> values.
>
> I like the flexibility that the configurable column names
> offer, but I can and will live with a 'Tough luck, hard-coded
> values are the way to go here...'

To be clear, my objection isn't so much that customizing the column
names is bad, but that it's inconsistent with the rest of realtime.  If you
wanted to create a set of patches that let you customize realtime options
across the board in some way that wasn't completely loony when you get
right down to it (like swapping named columns in the database simply by
changing a config file), I could see doing that.  The problem with that is
not that it's bad per se, but it's likely to cause a great deal of confusion
when somebody looks at a database and assumes that the value "dynamic"
in column "host" really means "host=dynamic" when in fact the host field is
configured to look at another column entirely.

That means headaches for those of us who manage the bugtracker when
somebody throws a tangled web at the bugtracker and says "X doesn't work",
when in fact, if you tracked down the web that was woven, X points somewhere
else entirely.

However, interface consistency is mainly what I'm going for at the moment.

-- 
Tilghman