[asterisk-dev] Understanding Voicemail Storage

[Steven]

On Wed, 2006-08-23 at 14:54 +0100, Alistair Cunningham wrote:
> Tzafrir Cohen wrote:
> > On Wed, Aug 23, 2006 at 02:05:47PM +0100, Alistair Cunningham wrote:
> >> Tilghman Lesher wrote:
> >> In some future version of Asterisk, it would be very nice to have 
> >> voicemail message file names be a unique identifier that never changes 
> >> for the message. This would make software that manages these files, such as:
> >>
> >> 1. Web interfaces.
> >>
> >> 2. Software to replicate mailboxes between Asterisk machines, keeping 
> >> track of which files have been deleted, etc, for purposes of high 
> >> availability.
> >>
> >> 3. Software to synchronise mailboxes with IMAP, Outlook, etc.
> >>
> >> more robust.
> > 
> > Maildir?
> > 
> > The imap storage goes at least a long way towards that goal.
> > 
> 
> Maildir would be ideal.

So here is a really cool idea. Let us step back and look at the original
posters suggestion and think about it. 

If we could make a simple(in api not neccessarily in implementation)
plugin library that handles storage and retrieval of the files and meta
data, then you could write a subsystem that handles your favorite style
of storage. 

With a storage library, developers could then write external apps that
don't have to worry about the underlieing storage. 

After getting this abstraction/plugin layer built, building the ODBC
connector should be less bug prone. IMAP sync should be really easy.
Taking the current file based solution and putting it in the new API
should be fairly easy and would eliminate the change shock.

Also it would help reduce replication of code when people want to make a
web based access to the voicemail storage. It allows one web interface
to have access to any storage method. Locking would only have to be
worried about in the storage plugin. 

So what would such a API need? Quick thought would be

READING:
Select mailbox
List of messages in mailbox
Details about specific message
Get handle for audio file suitable for handing to a read function to
play or send audio to another app.

WRITING:
New message
set details for new message
get temp file handle(useful for local file storage just recording to
proper location)
store audio
Delete message

QUESTIONABLE:
Thoughts here might be what about forwarding? Would it be benneficial
enough for subsystems to be exposed to the idea of forwarding or
broadcast messages? Such as would it be a good idea for some subsystems
to store only one copy of the audio file and link to it for multiple
messages. Then it can do garbage collection on the audio when it no
longer has any pointers to it.

-- 
Steven <critch at basesys.com>