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