Re: [Ipfc-developer] lib

[Glauber Reis]

 --- Tycho Fruru <address@hidden> escreveu: > On Mon,
2003-03-24 at 14:42, Glauber Reis wrote:
> > I have not downloaded IPFC from CVS yet (the
> firewall
> > admin does not pay attention to my demand), anyway
> I
> > am very impressed with it. At the same time i'd
> like
> > to ask some questions as to the lib implementation
> of
> > IPFC.
> > 
> > >From what I could see (and it is not much up til
> now)
> > the library behind IPFC is hardly linked to Perl.
> Isnt
> > it?
> 
> Well, IPFC is really a series of protocols.  There
> is an implementation
> of IPFC which is done in Perl (but other
> implementations are of course
> totally possible).
> 
I got it.
Would it be a problem if I'd branch the code?
Although IPFC overwhelms our idea here at work, It
does it in a manner that does not match our idea. So I
think we should branch it so that we could utilize it 
as a specialized remote configuration/monitoring
framework (with the very db-backend you use, since I
think your paradigm is perfect) but capable (if
needed) of comunication with the much broader
framework you develop. Any problem?

> On the "agent" side (eg. the stuff you install on
> your different
> machines who need to send logs to IPFC) perl is
> available on a number of
> different platforms (win32, most unices, some
> mainframe stuff) but this
> would indeed be the first place to look to change
> the implementation
> language.

I see it
> 
> > Does the develop team have any projects of
> > implementing IPFC based upon a C library and then
> wrap
> > it in a Perl module or use it from another
> language or
> > C itself ( many dont like Perl. For example, a
> monitor
> > for a W32 could be demanded but people would
> rather
> > use Delphi. What about a small footprint
> appliance?)
> 
> There is an appliance (which is called LogCollector)
> that's packaged
> (and sold) by us (Conostix).
> 
> > Is there any plan of make IPFC much more flexible?
> 
> Ah, but IPFC is already so flexible that most people
> don't see very
> clearly just what it can already do :-)

:-)
I did mean, flexible as in "I could use whatever
language I want in the "agent" side".
> 
> > What would be the major changes for the next
> > milestone? 
> 
> A non-exhaustive list of things we're working on
> right now :
> 
> - More efficient and accessible database format (so
> you can poke the
> data using something else than the perl API that's
> included right now)
> 
> - More intelligent backup support (full dumps of TB
> databases are no fun
> :-)
> 
> - Better compartimentalisation of tables in
> tablespaces (becomes
> important when you've got TBs of data to rotate)
> 
> - Ability to "re-parse" events (which is cool when
> you've updated a
> parser and want to treat all those old,
> not-yet-recognised events)
> 
> - Updates to buglets in the web user interface
> (mostly due to
> trigger-happy entity-encoding in the standard Perl
> libraries...)
> 
> 
> Cheers,
> Tycho
> 
> > 
> > 
> > Glauber Reis
> > 
> > 
> > 
> >
>
_______________________________________________________________________
> > Yahoo! Mail
> > O melhor e-mail gratuito da internet: 6MB de
> espaço, antivírus, acesso POP3, filtro contra spam. 
> > http://br.mail.yahoo.com/
> > 
> > 
> > _______________________________________________
> > Ipfc-developer mailing list
> > address@hidden
> >
>
http://mail.nongnu.org/mailman/listinfo/ipfc-developer
> -- 
> Tycho Fruru                                   address@hidden
> "Prediction is extremely difficult. Especially about
> the future."
>   - Niels Bohr
> 
> 
>  

_______________________________________________________________________
Yahoo! Mail
O melhor e-mail gratuito da internet: 6MB de espaço, antivírus, acesso POP3, 
filtro contra spam. 
http://br.mail.yahoo.com/