(Taking this to the mailing list for discussion.)
On Mon, Aug 04, 2014 at 12:40 -0500, you wrote:
> I think that script and any tests (assuming the plugin test
> infrastructure is in place?) need to move into the plugin.
Agreed in general. But there are two more general questions going in
here I
On Aug 4, 2014, at 3:48 PM, Robin Sommer wrote:
> So, in short: what would you guys think about solving the problem by
> moving DataSeries and ElasticSearch (including their scripts and
> tests) out into a new bro-plugin repository, but otherwise leaving
> things as they are right now?
Yeah, se
On Aug 4, 2014, at 4:48 PM, Robin Sommer wrote:
> Question is: do we want to change that? I'm reluctant to do
> that right now, as it would be major structural change, and we
> don't have much experience yet with the plugins' organization.
> I would prefer to leave the st
On Mon, Aug 04, 2014 at 21:15 -0400, you wrote:
> Mmmppphhh... Not sure if I should say "let's do it!" or not. I'm
> *really* tempted to say that we should make the break. We're early in
> the 2.4 dev cycle and now's the perfect time to get that plugin
> organizational experience.
Well, my pr
On Mon, Aug 04, 2014 at 22:03 +, you wrote:
> Yeah, seems like a reasonable first-step. I’m wondering if it makes
> sense to break them up even further in to separate repos like
> "dataseries-bro-plugin" and "elasticsearch-bro-plugin” ?
Yeah, I'm torn on this. It does make sense for the re
On Aug 5, 2014, at 4:41 PM, Robin Sommer wrote:
> On Mon, Aug 04, 2014 at 22:03 +, you wrote:
>
>> Yeah, seems like a reasonable first-step. I’m wondering if it makes
>> sense to break them up even further in to separate repos like
>> "dataseries-bro-plugin" and "elasticsearch-bro-plugin”
On Wed, Aug 06, 2014 at 00:04 +, you wrote:
> Was there more concern regarding admin overhead other than the initial
> cost of setting-up/mirroring? Is there a limit to how many repos can
> be mirrored?
No, it's indeed mostly the setup, plus the potential messiness of
having 1000s of indiv
On Aug 6, 2014, at 10:00 AM, Robin Sommer wrote:
> So do we want to go ahead with this model?
Sure. I’m thinking if a problem is found, it’s not hard to convert to one of
the other models since they should share the same directory structure and only
differ in which dirs are chosen to be git
On Wed, Aug 06, 2014 at 15:47 +, you wrote:
> I think that would be ok unless you’re worried about keeping the
> size/overhead of cloning bro down.
No, that's fine I think. I don't have particular worries, most of my
questions are just fishing for opinions on how we structure this best. :-
On Aug 5, 2014, at 5:33 PM, Robin Sommer wrote:
> So, I'm with you that should figure this all out, but I would prefer
> to do that as a separate step that for now leaves the existing
> structure in place until we know these answers.
I think you gave a good justification. Personally I am still
On Aug 6, 2014, at 11:00 AM, Robin Sommer wrote:
> One more question: would we then want to pull bro-plugin as a
> submodule into bro/aux? Then people would automatically get the stuff
> there as well (but it wouldn't be build automatically), and it would
> allow for easier testing as it's clear
On Wed, Aug 06, 2014 at 12:26 -0400, you wrote:
> I think you gave a good justification. Personally I am still a bit
> mixed on if we should even include the scripts that we put in
> base/protocols/ in with the analyzers.
Yeah, that's yet another decision to make ... Undecided. :)
Robin
--
On Aug 6, 2014, at 3:17 PM, Robin Sommer wrote:
> Also, if we integrated them into the central configure, we'd probably
> also need to provide their options, like --with-dataseries=/path/to/ds ...
Yep. I feel more and more like we're going to need the package management
system soon after (or
On Wed, Aug 06, 2014 at 12:33 -0400, you wrote:
> I don't like that stuff might not automatically build. Would it be
> possible to have the plugins add stuff to bro's configure output? So
> that plugins that are available and able to find their dependencies
> automatically build?
Hmmm ... Not
On Wed, Aug 06, 2014 at 15:23 -0400, you wrote:
> Yep. I feel more and more like we're going to need the package
> management system soon after (or in conjunction?) with this.
We'll need it eventually, but I wouldn't like to wait for it. Do you
think we'd break much by moving DS and ES into br
On Aug 6, 2014, at 3:37 PM, Robin Sommer wrote:
> We'll need it eventually, but I wouldn't like to wait for it. Do you
> think we'd break much by moving DS and ES into bro-plugins/, without
> building them automatically as well?
I'm not very fond of the ES support being even harder to get worki
On Wed, Aug 06, 2014 at 15:39 -0400, you wrote:
> I'm not very fond of the ES support being even harder to get working.
Any idea how widely that's used currently? It wouldn't be harder, but
a bit.
I think the alternatives right now are: (1) holding off completely on
moving readers/writers to p
On Aug 6, 2014, at 3:50 PM, Robin Sommer wrote:
> Any idea how widely that's used currently? It wouldn't be harder, but
> a bit.
Not very widely. It still has issues we're looking to correct too.
I think we can skip 1 and 2. :)
.Seth
--
Seth Hall
International Computer Science Institute
er
Sent: Wednesday, August 06, 2014 3:17 PM
To: Seth Hall
Cc: bro-dev@bro.org
Subject: Re: [Bro-Dev] Organizing plugins (Re: [JIRA] (BIT-1222)
topic/robin/reader-writer-plugins)
On Wed, Aug 06, 2014 at 12:33 -0400, you wrote:
> I don't like that stuff might not automatically buil
onable.
>
> -Gilbert
>
> From: bro-dev-boun...@bro.org on behalf of Robin
> Sommer
> Sent: Wednesday, August 06, 2014 3:17 PM
> To: Seth Hall
> Cc: bro-dev@bro.org
> Subject: Re: [Bro-Dev] Organizing plugins (Re: [JIRA] (BIT
20 matches
Mail list logo
