[asterisk-dev] [design] Realtime changes
tilghman at mail.jeffandtilghman.com
Mon Jan 5 11:47:26 CST 2009
On Wednesday 31 December 2008 15:07:11 Tilghman Lesher wrote:
> 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:
> <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.
> <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?
Here's the issue for this second method. Currently, when we store a
voicemail, we do so with a single operation, which specifies a binary type
for the blob field and text types for all other fields. With this change,
we'd be doing 2 operations for each storage of a voicemail. First, a realtime
store, which sets the main parameters of the voicemail (duration, origtime,
etc.) and a second blobupdate to actually store the binary audio.
I toyed with the idea of making a second store method, where the parameters
are specified in a set of 4 each, specifying name, value, type, and length,
but I'm not wild about that idea, either.
More information about the asterisk-dev