What are the opinions on completely removing the trace rewriter from
the Bro code base? I think I vaguely remember us discussing this,
with a conclusion that removing is the way to go, but I wanted to
check.
Pros of removing:
- Rewriter is broken right now anyway
- Not used by many people (just the "occasional researcher"
- Nobody knows the internals well.
- It's quite intrusive to the code, and removing it will get rid of
quite a bit of stuff sprinkled across the source.
Cons:
- It's pretty cool functionality and nobody else has it.
I really like the rewriting but I'm thinking it would be better done
in an external tool than inside Bro itself.
What are the opinions on completely removing the trace rewriter from
the Bro code base?
I would like to keep it. I hear you on the benefits of removing. However:
Cons:
- It's pretty cool functionality and nobody else has it.
Yep. It remains a striking demonstration of what's possible, IMHO, plus
it has for me a flavor of potentially leading to serendipitous uses. Also:
I really like the rewriting but I'm thinking it would be better done
in an external tool than inside Bro itself.
It doesn't make sense as an external tool. It uses the coupling between
Bro event generation and Bro policy scripts to do the rewriting. You'd
have to write Bro all over again.
Now, if you're willing to pledge that BinPAC++ will support rewriting
functionality .... then I could see removing the existing code.
That was indeed a thought I had, but because I don't want to
*pledge* it, I didn't say it; but you see where the "separate tool"
idea is coming from.
The problem with the rewriter is that either (a) we leave it broken
or (b) we need to spend significant time fixing it (and make sure it
doesn't immediately break again with future changes ...). The former
doesn't sound like a great option, but I'm not sure that the latter
is worth the effort.
We could do a compromise: Remove it, but turn all the code into a
big patch that applies cleanly to the next release. We wouldn't fix
anything for now, and we wouldn't maintain the patch for future
releases, but we'll keep the patch around if somebody comes along
who has an interest in doing (b) (which might just as well by
ourselves if at some point we want to spend our resources on that; I
don't see that near-term though).
Not sure what I am stepping into, but here I go. I agree strongly with Robin. It seems if it is broken now, then you don't really have a user community that you would disappoint. I don't see that (b) was really in line with any proposed work in the latest grant and would likely need a champion with funding to lead the effort to resurrect it. If the only reason to keep it is to show what can be done with Bro, the papers already do that and a broken piece of software doesn't help anyway.
Not sure what I am stepping into, but here I go. I agree strongly with Robin.
Yeah, I can appreciate that viewpoint. The counterpoint is;
I don't see that (b) was really in line with
any proposed work in the latest grant
Sure, but Robin is proposing actively yanking out code; I wasn't arguing
for putting further work into it, just leaving it be.
If the only reason to keep it is to show what can be done with Bro, the
papers already do that
Only somewhat, because for this sort of capability (which I do get inquiries
about time-to-time), telling folks that we removed it smacks of "it never
really worked", which is more harsh than I think is deserved.
In any case, I'm won over with the notion of having a coherent patch that
captures what's been removed.
Only somewhat, because for this sort of capability (which I do get inquiries
about time-to-time), telling folks that we removed it smacks of "it never
really worked", which is more harsh than I think is deserved.
(At some point I was trying to figure out what the last version was
in which the rewriter "just worked" out of the box. I don't remember
the details anymore but I had to go back *very* far, and even then
there was still some trouble I can't recall right now.)
In any case, I'm won over with the notion of having a coherent patch that
captures what's been removed.
Ok. If we do the yanking in a separate branch, it should be pretty
easy to make a big patch for putting the stuff back in; we just need
to reverse the direction of the branch's diff I would think.
Once the next release is out, we can also create a tagged branch
1.6-with-rewriter that has the patch already applied. Then we can
just point people to it. That's even easier than keeping the patch
itself around..
