> On Mar 8, 2018, at 1:28 PM, Jon Siwek <[email protected]> wrote: > > Hi all, this is just a status update on porting Bro to use the new > Broker communication system. I'd say the topic/actor-system branch is > now functionally complete with still a few weeks left of internal > cleanup/improvements.
Awesome, I'll get it deployed here on a test cluster. > Open questions: > > * Rename "proxy" nodes? > > The previous idea was to call them "data nodes", though I don't see > the benefit. It's awkward to talk about because there's no shorthand > for that node type: you can say "logger", "manager", or "worker", > though you'd have to say the whole "data node" phrase to make any > sense. That also shows that maybe it's helpful to name nodes based > upon a personifiable role that they play: "data" isn't a role/action > performed by a node/person. IMO, "proxy" is still accurate to the > role that these nodes perform: they are intermediaries for offloading > analysis and/or storage. Are there other ideas or is everyone wanting > to go ahead with "data node" ? I think I was the one calling them data nodes, but I only did that because that's what they were called in the original broker integration branch that Mathias Fischer started. I don't care about the name, as long as it's documented as a proxy node is for "offloading analysis and storage" that works for me. > * How much of the old comm. system to deprecate vs. remove? > > (1) &synchronized, &mergeable, &persistent. Seems fine to deprecate these > now. I'm fine with it going away, but there needs to be some sort of replacement for &synchronized, minimally a how-to for porting existing scripts to something else. I don't think anyone currently uses mergeable or persistent. — Justin Azoff _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
