Re: [OpenCALEA] Re: control design

[Jesse Norell]

  Agreed it would be good to have a web or some gui interface to stuff.
Rather than writing a wrapper around the current beginning framework
though, I'm more asking the question of whether this is the controlling
framework we want to end up with.

  The more I think about it, my answer is tending towards no.  I think
if we took a database (say mysql, the "M" from "LAMP") and define an
intercept in a table there, as well as defining all IAP's therein, we
can easily mark which IAP's should participate in an intercept, when it
starts/stops, etc.  Then have each IAP continually (once a minute or
whatever) checkin with that database and see if what it's doing needs to
change.

  This design would make writing "3rd party" controlling apps almost
trivial.  It also solves some of the security issues like making sure
"collector" can't be abused to kill other processes and the like.  It of
course also complicates other matters (eg. each IAP will have to be able
to monitor itsself), so I don't think it buys much overall simplicity,
but may be a better design in the end.

  One issue to consider with the current controlling framework is how to
control CmII data sources.  Having IAPs that all check a central db and
monitor themselves would I think make a more consistent interface in
that regard.




On Thu, 2007-04-05 at 15:27 -0400, Manish Karir wrote:
> 
> Hi Ken
> 
> Are you using the new collector/controller features in version 0.5?
> These were intended to add some sesssion management capability.
> 
> The collector process runs on the tap devices (where tap would run).
> Its role is to keep track of the various tap processing running
> on the device.
> 
> The controller process is run on a separate (and possibly remote)
> device.  Its role is to communicate with the collector processes and
> start/stop taps.
> 
> Are you building similar capability with your PHP application?  A PHP
> based front-end would be a great addition to the project! The community
> would really appreciate if you would be willing to contribute it
> to the code base.  I'm not exactly sure what sort of XML return values
> would help your application, perhaps you can describe it in a bit more
> detail?
> 
> thanks
> manish
> 
> 
> On Thu, 5 Apr 2007, Ken Jenson wrote:
> 
> > We are currently integrating a PHP application with a box running
> > OpenCalea.  We are creating php forms for Tap Config, Collector Config and
> > Tap session management.  We are writing a file that contains session
> > information so that on reboot we can restart those sessions.  All actions
> > are via 'shell_exec' using command line parameters.
> >
> > It would be nice to have some of the session management more automated.  It
> > would be nice to be able to easily query a list of tap sessions with their
> > attributes, start an stop them etc.  If the functions returned XML that
> > would be sweet.
> >
> > We are shipping next week so I guess some of my requests will need to wait
> > until a couple of versions later.
> >
> > I would love to see a LAMP wrapper, in fact, I wouldn't mind contributing
> > something to it..
> >
> > Ken Jenson
> >
> > On 4/5/07, Rich <w7ki@northwestradio.com> wrote:
> >> 
> >> 
> >> >>
> >> >>   Another option would be to define an "interception" in a database of
> >> >> sorts (rdbms or otherwise), and have every IAP source independently
> >> >> check that database periodically (frequently), and take appropriate
> >> >> action (eg. start/restart/stop an intercept, and send CmII events).
> >> >> There would still need to be an interface (possibly gui?) to define an
> >> >> intercept, and if each data source logged info it could also be used as
> >> >> part of the "secure and accurate record" we keep.
> >> >>
> >> >>   Ideas for other options are certainly welcome.
> >> 
> >> Perhaps we could make a 'LAMP' wrapper such that we can retain the
> >> simplicity of a command-line driven program while offering a GUI feature
> >> set
> >> to those who are interested.
> >> 
> >> Also, FWIW, everything compiles & runs on a vanilla CentOS 4.4 install.
> >> 
> >> - Rich
> >> 
> >> 
> >
> >
> > -- 
> > Ken Jenson
> > 801-224-6302 (hm)
> > 801-318-1200 (cell)
> >
-- 
Jesse Norell - jesse@kci.net
Kentec Communications, Inc.