Martin B. Smith wrote:
> I've been interested in the discussion @ the asterisk-user list about
> dialplan visualization tools; this is an area that I've also been interested
> in (as if I didn't have enough to do). But I've taken part of my weekend to
> toy with Stefan's additions for parsing configuration files, and I've built
> upon it. I've written some classes that parse (albeit terribly) the
> extensions.conf specifics (via some guidance from pbx_config.c). One thing I
> *do* use at work is JUNG (Java Universal Network/Graph Library). So I've
> attempted to use that to get some nice visualization.
What about a visual dialplan editor as an Eclipse plugin based on GMF
(http://www.eclipse.org/modeling/gmf/) or similar? :-)
> Unfortunately, I'm a little green (i.e. a novice) at designing good "usable"
> APIs that Asterisk-Java users might be interested in using, so for now, I've
> kept my code out of there. I've attached an example of the output run
> against the sample config that comes with Asterisk 1.4.19. I hope
> attachments work here!
Yep the attachment works. Looks nice.
What kind of an API do you think of? For the dialplan I could think of a
few classes like Dialplan, DialplanContext and Extension - maybe we can
even come up with a more general domain model of Asterisk concepts as we
already have similar classes in the live API (at least for Extension).
> Does this interest folks? Is it a direction that the Asterisk-Java project
> should explore?
Sure. I think this has a lot potential. Think of readin/changing the
config on the fly through the Manager API, parsing local files and
writing back changes or using the Asterisk Realtime Archtiecture
(storing config in the database). The domain model that is used there is
always the same.
> Is it bad design to ignore AEL and use handcrafted code for
> old-style "manual" parsing like Asterisk itself does?
No, i think using the underlying config format is the right choice. It's
the native format that Asterisk uses and AEL is just a preprocessor that
finally generates the config. If it is important to someone to use AEL
later on an AEL parser/transformer can certainly be written in Java, too.
> Heck, should we use
> JNI and use Asterisk's code directly for this (it's a maintainance
> nightmare, I would bet!)?
Oh no JNI! I've just finished integrating a speech recognition engine
that only provides a C interface through JNI the week before and I can't
tell you how glad I was when it was done and I could leave C-land again
and return to plain Java :-)
This would also limit the platforms you could use for deployment as you
would always need a matching Asterisk library (and I am not even sure
that it's easy to separate the config handling parts from the other
Asterisk stuff).
So what are the next steps?
=Stefan
--
reuter network consulting
Neusser Str. 110
50760 Koeln
Germany
Telefon: +49 221 1305699-0
Telefax: +49 221 1305699-90
E-Mail: ste...@re...
Jabber: ste...@re...
WWW: http://www.reucon.com
Steuernummern 215/5140/1791 USt-IdNr. DE220701760
|
