[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