[asterisk-dev] ast_flags now uint64_t ? should it be reverted ?

[Luigi Rizzo]

On Wed, Jul 18, 2007 at 01:22:47PM -0500, Kevin P. Fleming wrote:
> Steve Murphy wrote:
> 
> > But I agree with you-- the principle "minimal change" seems better; what
> > if I
> > created an analog to ast_flags, like ast_flags64, and a few APP_ARG
> > alternates that would use 64-bit flags, that apps with over 32 flags
> > (just dial, for now), could use, and use it only in dial, and revert
> > everything else back to normal?
> 
> If this change was made only to support ast_parseoptions() needing to be
> able to handle more than 32 option flags, then we should find a way to
> change it so that only ast_parseoptions() is affected.

exactly. Since app_dial.c can be easily reverted to use < 32 flags,
let's stay with that for now, and try to design a more flexible
ast_app_parse_options() before a need for the 32nd Dial option
comes.

And, to come back to the issue of 'too many options with cryptic
names', this is a problem that has to be faced, because i think
app_dial is well beyond any sane design principle.  One way to
approach this could be

    no new features in Dial(), for those who want them there is
    Dial2() which has all the features of Dial() plus the new ones,
    AND a different syntax.

So users of the old features will have to change nothing,
and for new features you only need to change individual
dialplan lines that actually use them.


Then in terms of restructuring the app, one could group
all "symmetric" options (such as wWtThHkK) as suboptions
of Caller() and Callee() options, remove things that can
be implemented more flexibly in other ways (e.g. all the
'privacy' stuff seems to be implementable with sort
of M() or U(), same for the announcements,...)

	cheers
	luigi