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 _______________________________________________ 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
