[Asterisk-Dev] Asterisk channel variable access: a proposal

[Tilghman Lesher]

On Wednesday 18 August 2004 13:37, Andrew Kohlsmith wrote:
> On Wednesday 18 August 2004 14:32, Tilghman Lesher wrote:
> > On Tuesday 17 August 2004 08:46, John Todd wrote:
> > > I hadn't really considered actually making it a filesystem in
> > > exactly the same way /proc worked; I just wanted to lay out the
> > > structure with the "/" as the inter-field designator, but keep
> > > the data inside astdb (or a shim in front of astdb.)  However,
> > > I suppose "asterisk -rx database get channels/SIP/2109-996a
> > > codec-in" would work for you to allow external programs to
> > > access that data in a hypothetical example.
> >
> > Ack.  No.  Please.
> >
> > Don't put transient call-related information into astdb (or even
> > in front of it, using a shim).  Astdb is for information that you
> > want to remain across calls and across invocations of Asterisk. 
> > It is _NOT_ for information which is call-specific.  That's why
> > we have channel variables.
> >
> > Note that I have no problem with the information being available
> > in that format, just with the idea of placing it within the
> > database (or making it seem like it comes out of the database).
>
> I quoted your entire response as I'm a little lazy and didn't want
> to cut and paste and attempt to reconstruct what you'd said.  :-)
>
> What are your feelings on a /proc-style filesystem for asterisk
> "live" data? That's precisely what /proc is like under Linux and it
> seems to make a *lot* of sense, at least in a transient data kind
> of sense.

Doesn't sound too bad.  I'd be interested in seeing your
implementation.

> I agree though that it should not hit any kind of real DB... that
> would hammer your I/O.

Well, it shouldn't hit the disk, at any rate.  My opposition is purely
from an API perspective:  I don't want transient data conmingled with
my semi-permanent data, at least in a way where I can't distinguish
the two.  It's fine to have the information available, but let's have
different APIs for accessing different types of data.

-- 
Tilghman