I can't speak to whether or not it is 'needed', but I have had desire to use it
in the past... The only thing preventing me from doing it was the fact that
Broker is currently a fast moving target.
Generally speaking, I was wanting to do it so that I could save state between
cluster restarts (specifically for authentication data).
________________________________________
From: bro-dev-boun...@bro.org [bro-dev-boun...@bro.org] on behalf of Matthias
Vallentin [vallen...@icir.org]
Sent: Sunday, July 24, 2016 2:43 PM
To: Siwek, Jon
Cc: bro-dev@bro.org
Subject: Re: [Bro-Dev] Broker data store API
> Not sure about the choice of RocksDB in particular — could have just
> been that it happened to pop up on people’s radar at the right time.
It's certainly an industrial-strength key-value, so I think it's solid
choice for those with better performance when needing persistence.
> Given those historical reasons for it existing, would make sense to me
> if it were temporarily ignored or removed completely (unless there’s
> people already invested in using it).
My plan was to put on hold for now, just to have less moving parts. It's
great that you've already invested the time to understand the API and
come up with an implementation. Same for SQLite. It took me only a day
to convert your backend code and read up on SQLite here and there. I
would imagine it will be the same for RocksDB.
That said, adding backends is fortunately a quite mechanical task. It's
easy to ship as an incremental release. I'm curious to find out what
types of backends they would like to see and use once they build
broker-enabled applications.
Matthias
_______________________________________________
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
_______________________________________________
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
