Re: [Bro-Dev] CBAN naming
Think the current name is fine, but if you change it I think it helps if it relates to things people know. So names like bpkg, bro-ports, or bro-brew would give the immediate analogy through the name. > On May 27, 2016, at 12:00 PM, Matthias Vallentin wrote: > > To find the new name for our CBAN project, it probably make sense to > brainstorm separately from the existing technical thread. I'd say let's > collect some candidates and then create survey to vote on them. > > Here are some ideas from the existing thread: > >- brow >- broil >- broom >- bpk >- berk >- bob >- bip > > Looking forward to hear your ideas. > >Matthias > ___ > bro-dev mailing list > bro-dev@bro.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev -- Adam J. Slagell Chief Information Security Officer Director, Cybersecurity Division National Center for Supercomputing Applications University of Illinois at Urbana-Champaign www.slagell.info "Under the Illinois Freedom of Information Act (FOIA), any written communication to or from University employees regarding University business is a public record and may be subject to public disclosure." ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] CBAN naming
Besides naming and skipping ahead to implementation, I highly recommend looking at how Rust manages crates. They are a pleasure to use and work with. -AK On May 27, 2016 5:38 PM, "anthony kasza" wrote: > Oh man. I don't know. Call it the colossal. > > -AK > On May 27, 2016 5:24 PM, "Matthias Vallentin" wrote: > >> > I like how Spicy was named, by choosing something completely different >> and >> > unrelated to the "bro" theme. >> >> I like that too. Do you have a suggestion? >> >> Matthias >> > ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] CBAN naming
Oh man. I don't know. Call it the colossal. -AK On May 27, 2016 5:24 PM, "Matthias Vallentin" wrote: > > I like how Spicy was named, by choosing something completely different > and > > unrelated to the "bro" theme. > > I like that too. Do you have a suggestion? > > Matthias > ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] CBAN naming
> I like how Spicy was named, by choosing something completely different and > unrelated to the "bro" theme. I like that too. Do you have a suggestion? Matthias ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] CBAN naming
Just my opinion... I like how Spicy was named, by choosing something completely different and unrelated to the "bro" theme. Or call it frat house. -AK On May 27, 2016 10:38 AM, "Azoff, Justin S" wrote: > > > On May 27, 2016, at 1:00 PM, Matthias Vallentin > wrote: > > > > To find the new name for our CBAN project, it probably make sense to > > brainstorm separately from the existing technical thread. I'd say let's > > collect some candidates and then create survey to vote on them. > > > > Here are some ideas from the existing thread: > > > >- brow > >- broil > >- broom > >- bpk > >- berk > >- bob > >- bip > > I don't have much of an opinion in the naming, just that we should avoid > using a name that already exists. > > I checked for collisions in debian(package names and filenames under > *bin/) the only tool that currently exists is 'bip' which is an irc proxy. > > There is a chef related tool called berkshelf: > https://github.com/berkshelf/berkshelf which installs a 'berks' command > > One thing that did come up was this: > > https://github.com/CompEvol/CBAN: Comprehensive BEAST Archive Network > > which doesn't seem terribly popular, but is actively in use. > > bpkg is another obvious name that is already in use: > https://github.com/bpkg > > > > -- > - Justin Azoff > > > ___ > 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
Re: [Bro-Dev] Broker status update
> > peer(x, y); // Create a peering between the two endpoints.
> > peer(y, x); // Idempotent. Peerings are symmetric.
>
> > x.peer(y); // Create a peering between the two endpoints.
> > y.peer(x); // Idempotent. Peerings are symmetric.
>
> I would prefer the 2nd way for consistenct, as all the other
> operations use the method-based scheme. The idempotency seems
> secondary to that I would say.
Okay, after mulling over this a bit more, I think the second version
makes sense also for another reason: overloads. Both of these statements
should be valid:
x.peer("127.0.0.1", 42000);
x.peer(y);
With a free function, this becomes not as clear anymore.
> Related question: what exactly are the semantics if only one side of
> the peering is set up?
The peering occurs asynchronously. The function endpoint::peer returns
void, and when the peering result (failure/success) becomes available, a
dedicated status message will be enqueued in the endpoint's mailbox.
This message has to be extracted via endpoint::receive, or in the
asynchronous case, there needs to be handler for the status present
(otherwise the message gets dropped).
> Hmm ... I see the appeal but it would introduce a new dependency and
> its Python-specific (I assume), whereas with SWIG it's easier to add
> more languages later. Is that worth the benefit of switching?
We already need SWIG and its Python-specific bindings, which are two
separate packages. Since every language has its idiosyncrasies, it's
quite unwieldy to have one framework to rule them all. At least SWIG
feels not like a productive toolkit for modern C++.
Also, since pybind11 is a small header-only package, we can easily ship
it directly with Broker, which would render the existing package
dependencies obsolete. That is, we would not introducing a new
dependency, but remove two instead ;-).
That said, this is my impression after just briefly looking at the
bindings space. I'll perform a more thorough evaluation once I'll
actually start delving into writing the bindings.
Matthias
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] CBAN naming
> On May 27, 2016, at 1:00 PM, Matthias Vallentin wrote: > > To find the new name for our CBAN project, it probably make sense to > brainstorm separately from the existing technical thread. I'd say let's > collect some candidates and then create survey to vote on them. > > Here are some ideas from the existing thread: > >- brow >- broil >- broom >- bpk >- berk >- bob >- bip I don't have much of an opinion in the naming, just that we should avoid using a name that already exists. I checked for collisions in debian(package names and filenames under *bin/) the only tool that currently exists is 'bip' which is an irc proxy. There is a chef related tool called berkshelf: https://github.com/berkshelf/berkshelf which installs a 'berks' command One thing that did come up was this: https://github.com/CompEvol/CBAN: Comprehensive BEAST Archive Network which doesn't seem terribly popular, but is actively in use. bpkg is another obvious name that is already in use: https://github.com/bpkg -- - Justin Azoff ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] CBAN naming
To find the new name for our CBAN project, it probably make sense to brainstorm separately from the existing technical thread. I'd say let's collect some candidates and then create survey to vote on them. Here are some ideas from the existing thread: - brow - broil - broom - bpk - berk - bob - bip Looking forward to hear your ideas. Matthias ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] CBAN design proposal
> On May 26, 2016, at 11:14 PM, Robin Sommer wrote: > >> Is it an important use case for the client to be able to interact w/ >> other repos that are structured like the one the Bro Team will be >> hosting? Seems less likely that people will want to do that >> especially if the CBAN repository is easy enough for people to submit > > Yeah, agree it's less important with that liberal model. I would still > like to support it though unless it's a major pain. Ok, I’ll plan from the beginning to be able point to multiple CBAN-like repository structures and then complain if I find out it’s complicated to support that. >> The client's “update” command will do a “git pull” in the parent repo >> and then a “git fetch” in any installed submodules. > > So does that mean the client ignores the version that the central CBAN > parent repository points to? Say Seth finished version 1.0 of his > cool-plugin and files a merge request. We add the submodule to CBAN; > it will point to 1.0. Then Seth updates to 1.1 on his end. CBAN would > still point to 1.0, but clients would just move their local clones to > 1.1, ignoring the parent repository's state. Is that what you have in > mind? Yeah, the parent repo would always point to the first version that was submitted, but when a user chooses to install something, that submodule gets initialized/cloned and the user can choose to use whatever version of it they want. And it won’t be the common case for a user to be doing any actual work inside the parent repo (unless they’re working on the cban client code), so it shouldn’t be a big deal if things like `git status` in the parent repo show a bunch of the “new commits” messages for each installed submodule. But I’ll also probably structure it so all submodules get cloned in to a subdirectory and then list that subdirectory in .gitignore to limit the noise. - Jon ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] CBAN design proposal
> On May 26, 2016, at 4:07 PM, Matthias Vallentin wrote: > > How do submodules scale? Or asked differently, what are the number > (order of magnitude) of submodules we're expecting? I imagine it will scale because when a user clones the main/parent CBAN repo, we’re telling them to just clone that and *not* recursively clone all the submodules (unlike the process for the ‘bro’ repo that you’re familiar with). Then the user will pick and choose the individual submodules they want. I don’t know much the average user will end up installing, but I’m guessing in the order of 10s and not 100s. Does that make sense or is there something more to your concern I might be missing or misunderstood? > Is the idea that all meta data will reside in a single file? What format > would that file be, YAML? If each user repo has 20 lines of meta data, > then the file would be 2KB to track 100 repositories. Seems fine to me, > but I wonder how much will end up in there to get a tractable upper > bound. I didn’t have a standardized format in mind to begin with, I just planned to do “the simplest thing that works” first and then let it evolve from there (clients can be updated in a way that’s resilient to changes in the format), but if enough people want to start w/ a particular format to begin with that’s fine too. > Binaries are a big project, I believe. Not only do we need to support > differently platforms, but also different OS versions and distributions. > It would probably mean we have to invest into a bigger Jenkins setup, > and then push the binaries into a CDN after a successful build. I imagined it would still be left up to individual authors to make precompiled binaries available and support/maintain them. It would also be optional for them to make binaries available, not required. - Jon ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
