[Bro-Dev] libbroker status/plans

Daniel Thayer dnthayer at illinois.edu
Wed Oct 22 13:45:25 PDT 2014


I tried building it on the newest version of debian, and got this error:

CMake Error at CMakeLists.txt:2 (cmake_minimum_required):
   CMake 2.8.12 or higher is required.  You are running version 2.8.9


Why does it need version 2.8.12 of cmake?



On 10/22/2014 02:39 PM, Siwek, Jon wrote:
> If anyone has time/interest, I feel like the main components of Broker are established now and deserving feedback/critique.  Rather than try to detail how things work here, it’s probably best for people to try figuring things out from the repo (e.g. source code comments and unit test examples) and ask questions about what's unclear.
>
> But it would be helpful to start a discussion on some of the planned features and open questions.  I’ll try literally pasting my TODO list and hope it’s readable.  The items are roughly ordered from most-certainty to least-certainty.  Feedback welcome generally, but particularly where questions are posed.
>
> Broker TODO
> ===========
>
> - C API
>
> - Python bindings
>
> - Persistent storage backend
>
> - SSL/IPv6 (dependent on actor-framework support)
>
> - Need/want overload or flow-control mechanisms?
>
>      E.g. a simple policy for handling overload is to let a user specify
>      a threshold for how many items are allowed in a queue before new
>      messages are dropped.
>
> - In-place data store value modifications
>
>      Plan to support increment/decrement on integral values.
>      Need any other operations?
>
>      What to do when applying an operation to invalid data type?
>      Plan to just send error message back to sender and leave further
>      decisions up to them.
>
> - Data store support for optional expiry model
>
>      What are the desired mechanims?  Options:
>
>          (1) Inserter may specify "expire this entry at time X" ?
>
>          (2) Inserter may specify "expire this entry based on
>              create/read/modification access time" ?  Going this route,
>              seems read access times would need to be shared across
>              clones (contradicts goal of lightweight, local read-access)?
>
>          (3) Other hooks to make expiry conditional?
>
> - Data typing model
>
>      Currently data in Broker is similar to Bro's threading::Value in
>      that full type info (from Bro's perspective) isn't available, just
>      the raw storage required for the types.  Broker currently differs in
>      that it doesn't use any tag to distinguish between primitives that
>      share the same storage (e.g. enum/string or double/interval).
>      Interpretation of types is left entirely up to the receiver.
>
>      Do we need more strict typing than this?  Options:
>
>          (1) Data holds additional type tag to suggest how to interpret
>
>          (2) Fully implement separate Bro-types.
>
>      Planning to try integrating w/ Bro as it is and see what specific
>      problems arise.  I think (1) may end up being helpful, but maybe not
>      required and I'd like to avoid (2) if possible.
>
> - Bro integration
>
>      Is Broker the default in Bro 2.4 ?  That implies requiring C++11.
>      Also I'm requiring CMake 2.8.12+ and may be hard to go below 2.8.
>      Bro is still happy with 2.6.3.
>
> _______________________________________________
> bro-dev mailing list
> bro-dev at bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
>


More information about the bro-dev mailing list