[asterisk-dev] app_voicemail.c refactoring

[Andrew Moise]

  So I'm trying for the Voicemail/IMAP synchronization bounty described at
http://www.voip-info.org/wiki/view/Asterisk+Bounty+VoiceMail-n-Email+Synchronization
.  It looks to me like the right way of doing that it to add a
"voicemail hook" interface to app_voicemail.c, whereby external modules
may read, delete, and move voicemails around, and also receive
notifications of new voicemails.  It's a bit similar to the "manager
interface" described at
http://www.voip-info.org/wiki/view/Asterisk+Voicemail+Redesign , but
from a different perspective.
  It looks like in order for that to happen in some form that's likely
to be accepted into asterisk SVN, app_voicemail.c must be refactored a
certain amount.  Clearly, a voicemail hook interface needs at least an
abstraction for voicemail messages and a set of functions for operating
on them.  I've been working on that (and some other random changes), and
I've posted some patches to Mantis.  The real meat of what I'm
interested in doing is shown in this patch:

http://bugs.digium.com/view.php?id=6512

  That creates a struct ast_vm_message, which is an abstraction for a
voicemail message, and some functions which operate on it.  It's not at
all complete; it's just enough to switch leave_voicemail() over to using
the abstracted interface instead of mucking directly with files.  It
should show the general shape of the changes I'm planning on making,
though.
  There are two much less interesting general-cleanup patches which
(unfortunately) must be applied before that one will apply; that's
because my planning was poor :-).  They are in Mantis at:

http://bugs.digium.com/view.php?id=6503
http://bugs.digium.com/view.php?id=6504

  Would anyone mind giving me some feedback on these ideas and patches
(particularly the first)?  I'd like to see this refactoring effort go
into SVN at some point, but I'm not entirely sure if the patches I'm
generating are in line with what the asterisk folk like to see, or how
to go about getting them into SVN if they are.

-- 
Andrew Moise <chops at demiurgestudios.com>