Join and rename tickets_api/ and events_api/

[bernhardreiter]

The advantage of having separate python modules was that a single module can be used independently,
e.g. with different access rights or from different machines.

Since the unification of stats subqueries, I expect tickets_api and events_api to e so similar
that joining them can be done while keeping the advantage. If this is done they should be renamed to
remove the "api" part, to indicate more strongly that they are not a general programming interface, but
just a backend interface for fody.

This would reduce the code duplication (part of solving #13).

[ghost]

Will the events API then still be usable even when not using OTRS as well?

[bernhardreiter]

@wagner-certat I'm unsure if I understand the question correctly. So guessing that you mean if somebody would use the endpoints, e.g. from an OTRS, would they still be available? Yes, the joining and renaming should not have an influence on the existing endpoints. You can run the modules with or without the additional intelmq-cb-mailgen tables.

So far we do not know if and how other people use the endpoints. If you know about usage, it would be cool to define it. And then we may turn the into an API at some point. (I believe an interface can be an API, if there are several using applications that are not fully dependent. fody-backend is not originally designed to be an API, just the backend for fody.)

Hope this clarifies a bit?

[ghost]

Currently, the events_api/Events Web-Interface of fody can be used without using a mailgen setup (which I mis-named above as OTRS) and is useful for a wider group of IntelMQ users (but I don't have usage numbers). I would just prefer if it stays that way, but of course I can't require it.

[bernhardreiter]

As written above:

You can run the modules with or without the additional intelmq-cb-mailgen tables.

So it would stay the way that you can use it without. :)