Re: resubmit your dbm/gdbm-based DLR storage patch and vote to phase out internal DLR storage in favor of DBM DLR storage

Hi Davy,

Davy Chan wrote:

> Hi Fred,
> 
> Now that we have UUIDs for each SMS passing through the bearerbox,
> would it be possible to modify your code to use standard dbm instead
> of gdbm.  That way, it could be compiled easily on most standard
> platforms.  For those wanting better performance, they can compile
> using gdbm in dbm compatibility mode.  If you don't have the time,
> then I would like to take over your code, modify it, and submit it
> for voting.
> 
> And, for all the Kannel coders out there, I would like to have
> a vote on phasing in a DBM-based DLR storage facility and phasing
> out the internal memory-based DLR storage.  The reason for including
> the DBM-based DLR storage would be that most UNIX or UNIX-like
> environments support DBM (really NDBM now) as a standard package.
> It would be the proper alternative to SQL-based DLR storage (instead
> of the in bearerbox's memory-only DLR storage).

I'm really -1 for dropping internal dlr storage. bdb or gdbm may be overkill
for small setups and forces external dependency (with is the goal why we
support mysql/pgsql/oracle). user should decide which one to use w/o
forcing them to install yet another database just to be able to use dlr's.

> 
> (My real reason to dump the internal DLR storage is that my statusbox
> is getting into trouble trying to gleam info from the bearerbox's
> internal memory DLR storage.  But, of course, phasing out a DLR
> storage that disappears with bearerbox's termination is a much better
> reason).
> 
> See ya...
> 
> d.c.

-- 
Thanks,
Alex