separate library from CLI about ssllabs-scan HOT 4 CLOSED

If @ivanr wants to break up the code base, I'll dig it. Personally, for this project, I don't think there's a lot of value for it. Abuse of the free-and-open API will be pretty high with this reference tool as it is.

Regarding repo feng-shui, I don't mind a project rename, but deep folder paths for something so simple, and superfluous eponymous directory names would probably cause me some rage. :-)

from ssllabs-scan.

I'd consider converting the code into a library (Go enables users to add their own code, for example to enforce their policies), but I don't want to do it just yet. At the moment I think we should focus on the basic features and then ensure that the API is rock solid. Once that's done, the client tool can be improved further.

I'll close this issue for the time being, but we can reopen it later.

from ssllabs-scan.

@cognusion "repo feng-shui" 😄 I like that. Though to be fair, part of it is completely necessary since go doesn't let you put different packages in the same directory. You could still eliminate the extra "cmd" directory, but that seems to be more common to make it clear that the contents there are individual binaries, not just sub-packages, and is modeled after core go itself. And with GitHub's new-ish folder jumping, it's not really any harder to navigate.

@ivanr, to your point, I would actually argue that having a cleaner separation between the client library (that is focused squarely on implementing the API exactly as documented) and the CLI (which is more concerned with user experience, parsing user input, etc) actually aids in helping to solidify the API and provides for an easier to understand reference implementation. But of course, this is mostly subjective, so it's entirely up to you.

from ssllabs-scan.

I agree with your point about the separation of concerns. My lack of desire to do it now is mostly due to the focus on delivering the first version of the API on schedule.

from ssllabs-scan.