ARSFI / winlink-mail-client

Open source email client program for the winlink radio email system
Apache License 2.0
15 stars 1 forks source link

Comments from the winlink forum #6

Open k0qed opened 1 year ago

k0qed commented 1 year ago

https://groups.google.com/g/winlink-programs-group/c/3DQkY6eW3zA

HarveyCreek commented 1 year ago

Looking at the Wiki:

Good over all goals! Cross platform should be a goal, though installation and setup should be bullet proof, hopefully something as simple as copy deploy. Updates should just replace that which has changed.

Quite concerned about using Web Browser GUI's to heavily. I've worked in computers since the card punch and paper tape days, and find that most browser based UI's lack in the ease of use features for the end user. Yeah, for the developer they are great, easy to deploy and a much smaller event base than coding for a Microsoft WPF application. Most remind me of the old IBM 3270 block mode CICS displays from the late 70's and 80's and just as clunky to use, as they often require a round trip to the server to perform validation. Also a require what I feel are clumsy work arounds to maintain state for validation and error management. Not to mention most have minimal context oriented displays minimal dynamic display of required depend fields, so tend to show every field that can be filled in rather than just those that should be. I've found the ICS-213 RR form is the hardest form to instruct operators to use. They don't grasp that different parts of the form are for different groups of the organization. Something like that needs to be built so only the fields related to the task at hand are displayed.

Modularity of a system described here is a must. But need to be very careful to make sure all can run standalone on a single workstation with no network connection. Maybe peer to peer WIFI now that most PCs seem to come with WIFI built in though security can be a little tricky to administrate for that.

Having use C# for the last 20 years, I am definitely biased toward accepting it being the current language of choice for the backend. Was responsible for supporting multiple 24x7 systems for power generation and distribution which mostly ran on Microsoft Windows.

Brian - W7OWO

tmiw commented 1 year ago

I think a lot of the pitfalls of web based UIs are avoidable now, especially with the existence of frameworks that can enforce doing the right thing. I've used Backbone.js before, for instance, but there are others (like AngularJS) that can be looked into.

On that note, there should probably be a coding policy put into place before coding really kicks off. That's something that will need to be discussed among ourselves and with the community for sure.

ad9cr commented 5 months ago

I share the concern about a web-based GUI. Putting interpreted code into wrappers around wrappers can really add up when you're considering running the application on constrained compute devices with limited battery life. It's easy to say "well modern devices are powerful enough that we don't need to worry about limitations like we used to", but in my opinion we're talking about software that could become critical in use cases where conserving power will really count.

tmiw commented 5 months ago

I share the concern about a web-based GUI. Putting interpreted code into wrappers around wrappers can really add up when you're considering running the application on constrained compute devices with limited battery life. It's easy to say "well modern devices are powerful enough that we don't need to worry about limitations like we used to", but in my opinion we're talking about software that could become critical in use cases where conserving power will really count.

Wouldn't the .pyc files that Python creates (basically JIT code IIRC) help at least somewhat with performance?

ad9cr commented 5 months ago

I share the concern about a web-based GUI. Putting interpreted code into wrappers around wrappers can really add up when you're considering running the application on constrained compute devices with limited battery life. It's easy to say "well modern devices are powerful enough that we don't need to worry about limitations like we used to", but in my opinion we're talking about software that could become critical in use cases where conserving power will really count.

Wouldn't the .pyc files that Python creates (basically JIT code IIRC) help at least somewhat with performance?

Something like this could help with the "server side", but they wouldn't run in the web browser. Possibly using something like Blazor (WebAssembly) could help there, but then I wonder how much of the perceived value of developing a web-based GUI could be eroded. The other thing that wouldn't be positively impacted would be the fact that you'd still have to push everything through HTTP.SYS (in Windows) to make HTTP calls across the tiers.

k0qed commented 5 months ago

What I had envisioned was a complete separation of the UI (browser based, but not necessarily) from the business logic with only a web services layer in between. I think this opens up the ability for differing UI's as well as easy remote access. A client app's UI would have virtually no impact on any computer that was capable of running the core processes (software modems, specifically).

-Lee

tmiw commented 5 months ago

I think something we should ask is what this should provide over something like Pat (other than being a first-party solution). After all, it already has the ability to use it over a console as well as through a web interface and apparently even has the ability to use VARA HF and FM. Once we know that, we can probably better decide how the architecture and UI should look.