Move checker-related stuff to its own repository

[ldruschk]

In my opinion, there is no reason why the C# EnoChecker is placed in the EnoEngine repository. Moving this to its own repository would help clarifying which part of the code are necessary to interface with any checker of the specified interface and which parts are relevant only to the checker server implementation in C#.

If there is any re-used code between the engine and C# checker, that should be cleanly placed in its own package.

[DanielHabenicht]

yep would be cool to have it in a enochecker-dotnet repository and renaming the other checkers accordingly, e.g. enochecker (which is python) to enochecker-python

[Trolldemorted]

I agree that a refactoring is necessary. Our requirements are:

• Code must be shared between EnoChecker, EnoEngine, EnoLauncher and EnoFlagSink
• Class definitions must be shared between EnoLandingPage Frontend, EnoEngine and EnoLauncher (scoreboard, attackinfo)
• Class definitions (IChecker and friends) must be shared between EnoChecker runtime and EnoChecker implementations
• The class definitions package must be as small as possible

Therefore we could split our packages in the following way:

• EnoCore.Models contains all basic class definitions that are shared between projects. It does not have any dependencies.
• EnoCore depends on EnoCore.Models.
• EnoDatabase remains like it is and depends on EnoCore.
• All logging-related functions and methods remain in EnoCore. Engine, Launcher, FlagSink and Checker depend on it (either directly or through EnoDatabase).
• EnoChecker is moved out of this repository.
• IChecker and friends follow EnoChecker and form a new project, e.g. EnoChecker.Core.

[DanielHabenicht]

IChecker and friends follow EnoChecker and form a new project, e.g. EnoChecker.Core.

Are you sure you want another package for Enochecker? I would just publish EnoChecker as it is in the new Repository. I think we both mean the same: Publishing EnoChecker as a new package.

[DanielHabenicht]

might it be useful to have PRs for refactoring this stuff? I think you have a typo in here: https://github.com/enowars/EnoEngine/commit/9c7139fde73c5056ab834a00f81907760402174b#diff-9bc0aa9f51ff6aedff652c211fa7771aff85093ba5c42432e263d0565c8b9e34R1

And in my last PR we talked about that everything should be LF, but now we are checking for CRLF? https://github.com/enowars/EnoEngine/commit/9c7139fde73c5056ab834a00f81907760402174b#diff-0947e2727d6bad8cd0ac4122f5314bb5b04e337393075bc4b5ef143b17fcbd5bR8

Whats about the dummy checker should we retain it somewhere for performance tests?

[Trolldemorted]

I think you have a typo in here: 9c7139f#diff-9bc0aa9f51ff6aedff652c211fa7771aff85093ba5c42432e263d0565c8b9e34R1

oh thanks, I guess we'll tend to that after enowars 5 is over though

And in my last PR we talked about that everything should be LF, but now we are checking for CRLF? 9c7139f#diff-0947e2727d6bad8cd0ac4122f5314bb5b04e337393075bc4b5ef143b17fcbd5bR8

No, you just commited a handful of CR files into an otherwise completely CRLF repo

Whats about the dummy checker should we retain it somewhere for performance tests?

yeah we should keep it with enochecker and provide prebuilt docker images, but that shouldn't be much work