Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

request etc. #5

Open
Iovesophy opened this issue Oct 15, 2021 · 2 comments
Open

request etc. #5

Iovesophy opened this issue Oct 15, 2021 · 2 comments

Comments

@Iovesophy
Copy link
Contributor

Iovesophy commented Oct 15, 2021

memo
I thought it would be better to define an interface , this is syntax of golang.
It will be more convenient if you can easily build with makefiles or anything else helper tools.
When detecting multiple hardware tokens, it would be nice to be able to choose which hardware to authenticate on , so should implement selector interface.
and I thought it would be better if there was a way to recover files in case of hardware failure, and it would be nice if users could choose that.

@Iovesophy
Copy link
Contributor Author

Iovesophy commented Oct 19, 2021

evidence of ( better to define an interface of syntax of golang )

see this info
https://go.dev/blog/package-names

Don’t use a single package for all your APIs. Many well-intentioned programmers put all the interfaces exposed by their program into a single package named api, types, or interfaces, thinking it makes it easier to find the entry points to their code base. This is a mistake. Such packages suffer from the same problems as those named util or common, growing without bound, providing no guidance to users, accumulating dependencies, and colliding with other imports. Break them up, perhaps using directories to separate public packages from implementation.

perhaps using directories to separate public packages from implementation.

so should separate directory of any yubikey control function.

memo -> https://zenn.dev/_kazuya/scraps/fdc65096b0d1d7

@kumo-rn5s
Copy link
Owner

All advice are going to Project board
Thank you for your comment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants