[Freeswitch-dev] apr_ vs. switch_ namespace questions
Michael Collins
mcollins at fcnetwork.com
Fri Nov 9 03:04:47 EST 2007
> Best policy is to use switch_ and not use the lazy apr_.
I tend to agree, at least from the standpoint of a non-coder who wants
(or needs) to read the source code.
> I cannot think of a good reason, maybe others can -- but,
I can't either. To preserve modularity, and to make it easier to
migrate away from apr if that need should arise, a clean and consistent
namespace seems appropriate.
> If you find occurrences of non-conformance, patches are welcome!
Sounds good. I'm studying up on apr (and thusly switch_xxx) and if/when
I'm comfortable submitting patches I will most definitely do so.
-MC
>
> m
>
>
>
> On Thu, 8 Nov 2007, Michael Collins wrote:
>
> > Guys,
> >
> >
> >
> > bkw gave me some homework and now I have a few questions. I notice
that
> > in switch-types.h there are all sorts of typedef struct statements
that
> > create a switch_ version of the corresponding apr_ type. However,
I've
> > also noticed that scattered throughout the source that there are
> > numerous occasions where the apr_ namespace is used even when there
is a
> > switch_ equivalent available. Example: using apr_pool_t instead of
> > switch_memory_pool_t in mod_openmrcp.c.
> >
> >
> >
> > Questions: Is it FS standard policy/best practices always to use
the
> > switch_ namespace? Are there legitimate situations where one would
> > prefer apr_ instead of switch_?
> >
> >
> >
> > Thanks,
> >
> > MC
> >
> >
> >
> > P.S. - If there are cases where apr_ is used when there are switch_
> > equivalents, does that mean there is an impending codebase cleanup
> > project to make everything consistent?
> >
> >
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
More information about the Freeswitch-dev
mailing list