[Taking to bro-dev] On Tue, Jan 15, 2013 at 09:39 -0800, I wrote:
> - we have been kicking around the idea of removing &synchronized > completely. it has a number of drawbacks (the loose semantics > and race condition; a lack of control for which nodes gets > updates) and internally it's very complex to implement. The idea > is to replace it with something simpler but more well-defined > (like a distributed key-value store) that would be wrapped with > script-layer frameworks to provide for easy use. Seth and I have been mulling over this, and I'd be curious what others think about this. If we'd remove the &synchronized stuff, we could throw out a lot of C++-level code and complexity. A distributed key-value store could probably be implemented simply as input/output plugins, and with the upcoming sqlite interface we'd get persistence built in there, too. That generally sounds quite appealing to me. The main drawback is that I/O capabilities would no longer directly map to Bro data structures, in particular it's not possible to keep references within non-atomic data types across the communication channel. Roughly speaking, we could exchange what we can currently log, but not more (i.e., no nested records, tables, etc.). On the other hand we could build script-level frameworks that get some of that back transparentky by rolling stuff out internally. We could even go a step further then and send events over that channel as well. And that in turn might let us eventually remove all the current communication code and replace with something nicer, maybe indeed an external library as we've been discussing earlier already. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * [email protected] ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
