Re: [OpenCALEA] Re: control design

[Manish Karir]

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)