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. /ast/IAX2/35210/codec /ast/IAX2/35210/peers /ast/IAX2/35210/jitter ... sounds *great* to me. I agree though that it should not hit any kind of real DB... that would hammer your I/O. -A. _______________________________________________ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
