Design philosopy and goals

[Vaasref]

Hi, at first I started by looking into that datetime bug, but I ended up starting to overhaul the library.

So I thought that it might be nice if you could activate the Discussions here so we can discuss about the project (design philosophy, its goals) without polluting the Issues.

I'm guessing the scope of my changes would require a bit of coordination before or even if I make a pull request.

[wh00hw]

Thank you @Vaasref , I converted the issue to discussion, feel free to explain your idea.

[Vaasref]

Thanks.

So while pyflipper is at its core a wrapper for the serial commands available on the Flipper, the amount of processing done before and after is subjective.

For example the most barebone wrapper could be simply abstracting the connection with the Flipper and handling the peculiarities and minutia of the communication itself (formatting the commands, waiting for prompt) and outputting the responses as strings or even bytes.

While a complete wrapper, basically a full API, could get between every aspect of the communication, encapsulating every returned error into python exceptions, (almost) every responses into its own object or data structure.

Currently I would say it(this repo) is mostly a simple wrapper with more developed functions (input verification and output parsing) when it comes to actually using the Flipper through the wrapper (as opposed tending to it).
On my fork, I am definitely pushing the more involved wrapper is not API-like at times.

I'm fine if my changes just sit there, I'm mostly doing it for entertainment purpose because let's be honest, there is no way I will reach a tenth of the time using the wrapper than developing it.
I consider what I'm doing as improving the wrapper, but doing so I break compatibility and adds a lot of noise in the sources due to docstrings data verification and exceptions. That's a price to pay that you may consider too steep for this repo/project.