[asterisk-dev] [design] Realtime changes
Dmitry Andrianov
dimas at dataart.com
Mon Jan 5 12:47:17 CST 2009
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
More information about the asterisk-dev
mailing list