Move checker-related stuff to its own repository about enoengine HOT 5 OPEN

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.

from enoengine.

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

from enoengine.

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.

from enoengine.

might it be useful to have PRs for refactoring this stuff?
I think you have a typo in here:
9c7139f#diff-9bc0aa9f51ff6aedff652c211fa7771aff85093ba5c42432e263d0565c8b9e34R1

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

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

from enoengine.

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

from enoengine.