mrkgnao: Could you explain what features you hope to have in gogcli that are currently missing from gogrepo(c)?
In all modesty, an observation that is made by looking at gogrepo's doc but not having managed to run it, I don't expect gogcli to include absolutely revolutionary features that will make gogrepo users say "omg, the tool I'm using is so passe, why didn't I think of doing my backups like that? Its imperative that I migrate now!". If you're already a happy gogrepo user, I encourage you to keep using the battle-tested tool that works well for you. Maybe I'm doing a lousy job of promoting my work here, but I'm a software engineer, not a salesman.
A couple features that are important for me (but probably won't matter for 95%+ of users):
- Support for redundant backups as a first class citizen (you can make one storage up to date with GOG.com and then propagate this to other storages in a robust minimalistic way without having to communicate with GOG.com again)
- Support for multiple storage solutions: I've taken a lot of interest in s3-compatible stores lately, especially Minio (
https://min.io/) for on-premise s3 storage... I'm also mongodb certified so its probable that I'll add a mongodb/gridfs store later one
- A modular design, its easy to QA various parts of the tool by running different commands sometimes by targeting only the gog api, but not the storage and at other times, but targetting only the storage, but not the gog api
In terms of codebase (which is important to me as I have the skills required to add features that I want), I won't say that my codebase is simpler (while over-engineering is a thing, its often a lazy argument to make, my codebase is probably more complex overall actually), but the complexity is distributed in a more modular way (the sdk part only worries about communication with the gog api, the cmd part mostly worries about executing commands on the prompt, the storage part mostly worries about storage, the manifest part only worries about the modelisation of the data, etc).
I won't claim that my modularisation is perfect (there are creeping business-logic concerns in the storage and cmd parts that irks at me, I'll see what I can do about refactoring that), but a reasonable effort has been made in this regard and this makes increasing code complexity as I'm adding features a lot more manageable for someone like me.
Some nice things for some users would be:
- The client is truly multi-platform (not Linux or Windows specific thing, you just need to get the binary for your platform and you are in business)
- The client is a self-contained binary (you don't need to have dependencies like Python or some library installed on your machine)
- The client has some low level commands to interact with the gog api (if you'd like to script something on top of the client for example)
- The client uses a battle-tested command-line library (Golang's Cobra) which makes it more user-friendly for running commands: You get detailed outputs for the commands, subcommands, arguments and the posix convention is respected (which will be familiar to a lot of people)
Beyond that,the mechanism to authenticate is more basic, which is a double-edged sword (and something I would like to eventually revisit). The client currently doesn't try to login for you, it just expects you to put two cookie values in a file.
If you don't know anything at all about http, cookies and how to access them in your browser dev console, that will probably be hell. However, if you know how to do that, then you won't have to content with a finicky login mechanic that will sometimes work, sometimes fail.
