<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><div>Hi Sebastian,</div><div><br data-mce-bogus="1"></div><div> 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. 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><div><br data-mce-bogus="1"></div><div>wrapper BotA | wrapper BotB | wrapper BotC ...</div><div><br data-mce-bogus="1"></div><div> so I was struggling to find good use cases to support a library implementation.</div><div><br data-mce-bogus="1"></div><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 :-). 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><br data-mce-bogus="1"></div><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><br data-mce-bogus="1"></div><div>Br, Mika</div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><b>From: </b>"Sebix" <sebix@sebix.at><br><b>To: </b>"intelmq-dev" <intelmq-dev@lists.cert.at><br><b>Cc: </b>"Mika Silander" <mika.silander@csc.fi><br><b>Sent: </b>Tuesday, 25 April, 2023 13:05:50<br><b>Subject: </b>Re: [IntelMQ-dev] RFC on IEP007: Running IntelMQ as Python Library<br></div><div><br></div><div data-marker="__QUOTED_TEXT__"><p>Dear Mika,<br>
</p>
On 4/25/23 11:28 AM, Mika Silander wrote:<br>
<blockquote>
<pre class="moz-quote-pre"> Reading through the IEP in question, I thought I would find reasons or motivations as to why having a library is desired. It's possible I've missed discussions or mails and the reasons have been discussed/documented elsewhere.</pre>
</blockquote>
Thanks for the input, I'll try to find some references from the 3.0
discussions when we first discussed this feature request in more
details, or otherwise expand this section on my own.<br>
<blockquote>
<pre class="moz-quote-pre"> If the implementation you choose for IEP is the API-breaking generator one
</pre>
</blockquote>
<p style="color:rgb( 14 , 16 , 26 );background:transparent;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb( 14 , 16 , 26 );background:transparent;margin-top:0pt;margin-bottom:0pt">I think there
was a misunderstanding: It is precisely the </span><em style="color:rgb( 14 , 16 , 26 );background:transparent;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb( 14 , 16 , 26 );background:transparent;margin-top:0pt;margin-bottom:0pt">question</span></em><span style="color:rgb( 14 , 16 , 26 );background:transparent;margin-top:0pt;margin-bottom:0pt"> if we also want to address this
topic. It has its pros and cons, whereas the biggest downside is
the API-breaking part with all its implications.</span></p>
<p style="color:rgb( 14 , 16 , 26 );background:transparent;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb( 14 , 16 , 26 );background:transparent;margin-top:0pt;margin-bottom:0pt"><br>
</span></p>
<p style="color:rgb( 14 , 16 , 26 );background:transparent;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb( 14 , 16 , 26 );background:transparent;margin-top:0pt;margin-bottom:0pt">You know that
it was a long and bumpy road towards IntelMQ 3.0, and
accumulating multiple significant development steps in a short
period was challenging (OTOH had the - temporary - development
capacity at that time to make this leap). I'm fully aware that
breaking changes can mean a lot of trouble and I'm all for
small, separated steps (hence this IEP), which allow more
straightforward discussion, review and maintenance. When writing
PoCs for this IEP, I found a similar area for improvement in
IntelMQ which could also be interesting to tackle. It is not up
to me to decide the direction of the IntelMQ roadmap but to the
<i>community</i>. Hence, I posed this question and asked for
comments, and I am very grateful that you are contributing so
actively through code and discussion.</span></p>
<p style="color:rgb( 14 , 16 , 26 );background:transparent;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb( 14 , 16 , 26 );background:transparent;margin-top:0pt;margin-bottom:0pt"><br>
best regards<br>
Sebastian<br>
</span></p>
<p>-- <br>
</p>
<pre class="moz-signature">Institute for Common Good Technology
gemeinnütziger Kulturverein - nonprofit cultural society
<a href="https://sebix.at/" target="_blank" rel="nofollow noopener noreferrer">https://sebix.at/</a>
ZVR 1510673578</pre><br></div></div></body></html>