<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
<p>Dear Mika, dear Aaron,</p>
<div class="moz-cite-prefix">On 4/25/23 1:43 PM, Mika Silander
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:655707806.9788282.1682423023667.JavaMail.zimbra@csc.fi">
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<div style="font-family: arial, helvetica, sans-serif; font-size:
10pt; color: #000000"> References to the discussions on
motivations for the library proposal are welcome, but when and
if you find them, IMHO I think the best location for them is the
IEP itself. The document could for example, start with a
"Background" or similar section that tries to answer why this is
a desired thing, what benefits it would bring and maybe some
examples.</div>
</blockquote>
<p>I have added a new section with another example and a proposal
how it can/will be used in the IntelMQ Webinput:<br>
</p>
<p><a class="moz-txt-link-freetext" href="https://github.com/certtools/ieps/tree/iep-007/007#user-content-use-cases">https://github.com/certtools/ieps/tree/iep-007/007#user-content-use-cases</a></p>
<p>The code examples are not yet consistent, as they are to be
discussed and I work on proof of concepts (i.e. researching what
interface options are possible/doable) in parallel.<br>
</p>
<blockquote type="cite"
cite="mid:655707806.9788282.1682423023667.JavaMail.zimbra@csc.fi">
<div style="font-family: arial, helvetica, sans-serif; font-size:
10pt; color: #000000">A long time ago I wrote a wrapper script
that allowed chaining bots on the command line. It did of course
not provide all the features that are outlined in your IEP, but
it gave me the possibility to simple sampling of events and
testing bots with e.g.
<div><br data-mce-bogus="1">
</div>
<div>wrapper BotA | wrapper BotB | wrapper BotC ...</div>
</div>
</blockquote>
Oooh, that's interesting as well! Although not the same as this
proposal, it somehow goes in a similar direction<br>
<blockquote type="cite"
cite="mid:655707806.9788282.1682423023667.JavaMail.zimbra@csc.fi">
<div style="font-family: arial, helvetica, sans-serif; font-size:
10pt; color: #000000">
<div> What comes to the API-breaking vs. less intrusive
implementation, I think I did understand these were two
separate options, but the API-breaking I found a bit scary and
reacted to that only. And yes, I can imagine it's been a big
effort to reach versions 3.0 and 3.1. Had I known all the
effort I've had to do put to the interconnected systems
related to our IntelMQ setup (IntelMQ itself was not that
hard), I would have never even started :-).</div>
</div>
</blockquote>
Hehe, oh yeah, I feel your pain. Getting systems interconnecting
together, month-long fiddling around in various scripts, and setting
up proper management, monitoring, other supporting systems around
all that, docs - lots of work.<br>
<blockquote type="cite"
cite="mid:655707806.9788282.1682423023667.JavaMail.zimbra@csc.fi">
<div style="font-family: arial, helvetica, sans-serif; font-size:
10pt; color: #000000">
<div>Still, as said, my vote is on the less intrusive
implementation option and sticking to KISS, but if it turns
out the API-breaking one wins, please consider techniques that
could provide some degree of backward compatibility as I
suggested.</div>
</div>
</blockquote>
ACK<br>
<blockquote type="cite"
cite="mid:655707806.9788282.1682423023667.JavaMail.zimbra@csc.fi">
<div style="font-family: arial, helvetica, sans-serif; font-size:
10pt; color: #000000">
<div> I don't think I'm a very active debater on this forum, so
it would be nice to read what other developers think.
Especially the ones like me who do not form part of the core
developers but just need to add some components and features
of their own to IntelMQ.</div>
</div>
</blockquote>
<p>+1<br>
</p>
<div class="moz-cite-prefix">On 4/25/23 1:52 PM, L. Aaron Kaplan
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:E7550CBC-5293-47E5-ACC4-3CD6C7D992BE@lo-res.org">
<pre class="moz-quote-pre" wrap="">I think maybe it also helps to clearly explain what Sebix meant by "API breaking change"?</pre>
</blockquote>
The word "API" has two meanings here<br>
1. The program "IntelMQ API", the managers interface<br>
2. The application program interface of IntelMQ (Core) itself, i.e.
the methods, its parameters etc.<br>
<blockquote type="cite"
cite="mid:E7550CBC-5293-47E5-ACC4-3CD6C7D992BE@lo-res.org">
<pre class="moz-quote-pre" wrap="">I.e. internally the API for the Bot class changes (and can be search&replaced & refactored for all code and all the developers get informed) Or... this also breaks the (hug/fastapi) API ? ;-)</pre>
</blockquote>
<p>In this case I meant the program interface of IntelMQ and more
specifically I addressed the function signature of Bot.process. A
change here would mean the process() methods need to be adapted,
or a compatibility layer introduced (is possible with Python's
built-in code inspection).</p>
<p>So far, we all agree that we do not want to make this step (now).</p>
<p>best regards<br>
Sebastian<br>
</p>
<pre class="moz-signature" cols="72">Institute for Common Good Technology
gemeinnütziger Kulturverein - nonprofit cultural society
<a class="moz-txt-link-freetext" href="https://sebix.at/">https://sebix.at/</a>
ZVR 1510673578</pre>
</body>
</html>