[asterisk-dev] [design] Realtime changes

Matthew Nicholson mnicholson at digium.com
Tue Jan 6 09:35:24 CST 2009


I think this is the right approach.  Even with a realtime backend for
odbc and imap, you still need #ifdef support for using filesystem
storage.  Having an abstraction layer for the storage of voicemail is
the best way forward IMO.

On Mon, 2009-01-05 at 21:47 +0300, Dmitry Andrianov wrote:
> Tilghman,
> While I do not see anything bad with such an extension of realtime API, I believe that it is not the best design for voicemail ODBC. Using this approach you will most likely succeed with ODBC storage but I hardly understand how you will approach IMAP one as you plan. With IMAP storage you need a concept of session/transaction which realtime API does not provide. Even for ODBC storage using realtime look a bit unnatural to me (I know, tastes differ).
> 
> The voicemail application became too complex as more storages were supported. Now it is huge bunch of code with endless #ifdefs. To my taste, the only way to improve this is to create an abstraction layer to separate voicemail logic from the storage used. Some time ago inspired by old patches on Mantis I started the work of separating voicemail application logic from the storage it uses. Unfortunately I had no time to do any significant progress with it but the idea was to have a "storage driver" which supports all the operations voicemail needs to perform.
> 
> I'm providing API of the storage below to give you an idea.
> 
> So the bottom line - if the only purpose of extending realtime API is the Voicemail application, I do not think it is the best improvement the Voicemail needs. If there are other uses for the API - no objections then.
> 
> Regards,
> Dmitry Andrianov
> 
> struct vm_message {
>         int     dir;                            /* Folder */
>         int     msgnum;                         /* Message number within the folder */
>         char    file[PATH_MAX];                 /* Absolute file name (without extension) on the local filesystem */
>         char    fmt[80];
>         char    category[100];
>         int     duration;                       /* Duration in seconds */
>         time_t  origtime;
>         char    mailbox[AST_MAX_EXTENSION];
>         char    context[AST_MAX_EXTENSION];
>         char    cid_name[AST_MAX_EXTENSION];
>         char    cid_num[AST_MAX_EXTENSION];
>         struct vm_storage *storage;
> };
> 
> #define VM_MSG_FLAG_TEMP                (1 << 0)
> #define VM_MSG_FLAG_RETRIEVED           (1 << 1)
> #define VM_MSG_FLAG_STORED              (1 << 2)
> 
> #define VM_MSG_NUM_NAME                 0
> #define VM_MSG_NUM_UNAVAIL              1
> #define VM_MSG_NUM_BUSY                 2
> #define VM_MSG_NUM_TEMP                 3
> 
> struct vm_mailbox;
> 
> struct vm_storage {
>         /* Mailbox manipulation */
>         struct vm_mailbox *(*open_mailbox)(struct ast_vm_user *vmu, struct vm_state *vms);
>         int (*close_mailbox)(struct vm_mailbox *mbox);
>         int (*open_folder)(struct vm_mailbox *mbox, int folder);
>         int (*close_folder)(struct vm_mailbox *mbox);
> 
>         /* Message manipulation */
>         struct vm_mesage *(*retrieve_message)(struct vm_mailbox *mbox, char *dir, int msgnum);
>         int (*dispose_message)(struct vm_mailbox *mbox, struct vm_mesage *msg);
> 
>         struct vm_mesage *(*make_message)(struct vm_mailbox *mbox);
>         int (*store_message)(struct vm_mailbox *mbox, struct vm_message *msg, int dir);
>         int (*copy_message)(struct vm_mailbox *mbox, struct vm_message *msg, int folder);
>         int (*move_message)(struct vm_mailbox *mbox, struct vm_message *msg, int folder);
>         int (*delete_message)(struct vm_mailbox *mbox, struct vm_message *msg);
> 
>         /* Informational */
>         int (*message_exists)(char *dir, int msgnum, char *filename, const char *preflang);
>         int (*count_messages)(struct ast_vm_user *vmu, char *dir);
>         int (*last_message_index)(struct ast_vm_user *vmu, char *dir);
> 
>         /* Message operations -- exported to the rest of asterisk via ast_install_vm_functions */
>         int (*message_count)(const char *context, const char *mailbox, const char *folder);
>         int (*inbox_count)(const char *mailbox, int *newmsgs, int *oldmsgs);
>         int (*has_voicemail)(const char *mailbox, const char *folder);
> };
> 
> struct vm_mailbox {
>         struct ast_vm_user *vmu;
>         struct vm_state *vms;
>         struct vm_storage *storage;
> };
> 
> 
> 
> -----Original Message-----
> From: asterisk-dev-bounces at lists.digium.com [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Tilghman Lesher
> Sent: Thursday, January 01, 2009 12:07 AM
> To: Asterisk Developers Mailing List
> Subject: [asterisk-dev] [design] Realtime changes
> 
> Once again, I am proposing some realtime changes, this time in the quest
> to make voicemail ODBC storage completely dependent upon realtime, instead
> of containing its own set of ODBC commands.  This may eventually allow us to
> make even IMAP a realtime backend of sorts.
> 
> The two APIs that I am proposing adding are as follows:
> 
> ast_copy_realtime("family",
>         <criteria>, SENTINEL,
>         <field-list>, SENTINEL,
>         <new-fields>, SENTINEL)
> 
> where <criteria> is a set of pairs of data, with at least one pair
> specified, detailing the criteria for selection of a row to copy; <field-list>
> is a list of fields to copy directly; and <new-fields> is a set of data pairs,
> specifying field names and values to insert along with the fields that are
> being copied.  For SQL-based databases, this command roughly translates
> to:
> INSERT INTO "family" (<field-list>,<new-fields-names>) SELECT
> <field-list>,<new-fields-values> FROM "family" WHERE <criteria>;
> where <new-fields> are separated into their respective field names and
> field values.
> 
> ast_blobupdate_realtime("family",
>         <criteria-pairs>, SENTINEL,
>         <field-name>, <blob-value>, <blob-len>, SENTINEL)
> 
> This should allow us to store Binary Large OBjects into the realtime database
> without needing to worry about embedded NULLs in the data.
> 
> Anybody feel strongly that I should do either of these a different way?
> 
> --
> Tilghman
> 
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
> 
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
-- 
Matthew Nicholson
Digium, Inc. | Software Developer




More information about the asterisk-dev mailing list