Re: [Bro-Dev] CBAN design proposal

On Thu, May 26, 2016 at 15:57 +, you wrote: > But we are wrapping everything in the Bro plugin architecture, right? I think we'll need to play with that a bit still to see how exactly a minimal script module would be distributed. The binary plugins require a bit more structure, and are

Re: [Bro-Dev] CBAN design proposal

On Thu, May 26, 2016 at 14:07 -0700, you wrote: > Is it necessary to enforce this? Intuitively, I would just leave > namespacing to the user. No need to enforce, but it would be good to have some guidelines at least. And part of the guidelines should be keeping the "Bro" namespace reserved. >

Re: [Bro-Dev] CBAN design proposal

> Here are some bro'ish suggestions (not all are serious ones): > > - brow (part of the logo already) > - broom (sweep new code into bro) > - broil (Bake your enhancements into bro) > - broad (extends Bro in a broader sense) > - broem (pleasing in a literary manner) > - bropane (hot stuff for

[Bro-Dev] Configurable _expire interval

Hi, I ran into an issue while trying to make the _expire interval configurable: Using a redefable constant does not work here, as the expression only gets evaluated when the table is initialized and thus later redefs do not influence the value. I thought about circumventing this by setting the

Re: [Bro-Dev] CBAN design proposal

> - having both "upgrade" vs "update" commands sounds confusing, I'm > sure I would constantly mix up the two. Suggest to rename one of > them. I think this comes from Homebrew (and maybe other package managers as well). I kinda got used to it in this context, but occasionally still trip over

Re: [Bro-Dev] CBAN design proposal

> On May 26, 2016, at 10:46 AM, Robin Sommer wrote: > > - Let's keep BroControl integration in mind at leat. I agree that a > standalone client makes most sense right now, but if there's > something we can do that will make it easier for BroControl later to > integrate,

Re: [Bro-Dev] CBAN design proposal

CBAN is a good name. It’s short, easy to say, and what the acronym means, the “Comprehensive Bro Archive Network”, makes sense. But I don’t really have a dog in this fight. -- Jeannette Dopheide Training and Outreach Coordinator National Center for Supercomputing Applications University

Re: [Bro-Dev] CBAN design proposal

> On May 26, 2016, at 10:46 AM, Robin Sommer wrote: > > - Terminology 1: agree that we should find a better name for CBAN. BroForge? > > - Terminology 2: Using "plugin" as the entity name for everything is > confusing I think, as right now I think most people understand it

Re: [Bro-Dev] Option -z

> If one > could express such analyses easily with a few lines of script code, > that would be quite powerful for doing script inspection that's also > easy to customize. Well sure, but it's not clear one can get to that point without some significant work under the hood anyway in terms of the

Re: [Bro-Dev] Option -z

On Thu, May 26, 2016 at 07:41 -0700, you wrote: > I wonder if they don't use it because it's not on their radar. It's > actually pretty handy, I see that in principle but hardcoding the functionality in C++-land doesn't seem to be the ideal way to go about things like this. If one could

Re: [Bro-Dev] Option -z

> Just removing this specific use > of finding NOTICEs, which doesn't seem anybody has been using in a > long time. I wonder if they don't use it because it's not on their radar. It's actually pretty handy, a way of telling when you think the set of NOTICEs should be X, but it's actually X'.

Re: [Bro-Dev] Option -z

> On May 26, 2016, at 10:15 AM, Robin Sommer wrote: > > > > On Wed, May 25, 2016 at 20:56 -0700, you wrote: > >> Well it's there in CHANGES, per the appended. But yeah looks like it never >> went anywhere beyond the original instigation, so I think removing it is >> okay. >