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

[John Todd]

At 3:12 PM -0500 on 8/18/04, Tilghman Lesher wrote:
>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

My comments earlier about this being a 'database-like' structure were 
only because the /proc filesystem format resembles astdb, which in 
turn resembles a (flat) database.  I agree that none of this should 
typically hit a disk, or even "exist" until requested.

I think that we've got the astdb structure already in place for 
certain core variables, and perhaps it makes sense to just extend 
this format.  Creating a "top-level" structure like "/var" or "/tmp" 
might be able to allow easy determination between values that get 
stored across restarts (like /SIP does) and values that don't get 
stored which are per-call based.  This could just be trying to 
shoehorn things into the wrong structure; I'm just trying to present 
ideas in an already-understood syntax that we have on-hand.

An alternate method would be to create an application, as has been 
suggested.  This may be more modular and require less patches to the 
"mainline" code (though that is a poor reason to choose one method 
over the other - "convenience of explanation and patching")

The third method would be to completely re-work Asterisk, as has also 
been suggested.

JT