[asterisk-dev] [svn-commits] tilghman: trunkr86065-/trunk/apps/app_meetme.c
Dan Austin
Dan_Austin at Phoenix.com
Wed Oct 17 16:53:27 CDT 2007
Tilghman wrote:
> On Wednesday 17 October 2007 15:32:02 Dan Austin wrote:
>> Tilghman wrote:
<Snip>
>> 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.
I had thought I had seen another instance of 're-mapable'
column names either in the WiKi or similar site, but of course
I cannot find it now.
> 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.
Fully understood. I feel/felt dirty even asking for the
approach to be considered...
> However, interface consistency is mainly what I'm going for at
> the moment.
Agreed. I know that there has been talk about re-doing
the whole RealTime architecture, but I do not think I have
seen any branches, team or otherwise, with a work in progress
of the rewrite. It might be handy to consider this level
of configurability during the rewrite (when/if it happens).
So I think I will withdraw my request for re-adding the
column name options, and will handle the fall-out in the
Web-MeetMe support forums. I'll likely have three variants
to support, legacy db setups with the current column names
using an out of tree scheduler app, new installs with
'proper' column names from the start, and upgraded systems
that have the column names changed to the correct names.
Thanks for reviewing and applying the patch,
Dan
More information about the asterisk-dev
mailing list