Language selection

[tmiw]

I noticed on the wiki that the proposed language is C#. It may be worth considering other options if they can interface with any third party libraries that would be needed. (For example, I use Python occasionally and have been able to knock out stuff pretty quickly, including this reporting tool for the other ham radio project I work on.)

Speaking of which, is there any stuff already in the repo (like winlink-web-services) that would be useful to use?

[k0qed]

I was thinking C# for the backend, but it could be any language. If using a web interface the backend would likely be a service/daemon.

The web services project could be added. It or something like it will be needed to interface to the CMS.

[tmiw]

I took a look at the web services and it doesn't seem like there's anything that would strictly require us to keep using the C# API. In fact, it seems you can pass straight JSON to it and get JSON responses, so really anything could support it.

FWIW, Pat seems to use Go. I actually have never messed with Go but people seem to like it.

[k0qed]

I agree, there's nothing about the web services that would require any specific language. But the backend of the app will likely draw from existing application code that is primarily C# or VB.Net. Converting that to a completely foreign language would be quite an effort.

[tmiw]

I agree, there's nothing about the web services that would require any specific language. But the backend of the app will likely draw from existing application code that is primarily C# or VB.Net. Converting that to a completely foreign language would be quite an effort.

Since there is a JSON based way of accessing it, there theoretically could be a library that helps a bit with the boilerplate (even if it was something this project had to write). C# would be the lower friction option for sure, though.

Anyway, I wonder if we need to solicit input from the community to make sure that we've captured all the desired features and pain points. That would help narrow down the possible language options (or even confirm to us that C#/.NET is fine).

[k0qed]

I've invited Lor to take a look and offer suggestions. Please edit the readme or wiki as you see fit. As soon as we hear from Lor, I agree, we should open it up to the community.

[k0qed]

A couple of people have sent emails expressing a desire to help out with Winlink dev. I've pointed them to this repo this morning.

If you wouldn't mind, please go ahead and make the public announcement of the project.

[w3qalor]

Sorry for the late reply. Was totally absorbed all weekend on an assignment to run a COMU for a major air show at Seymour Johnson AFB. (Photo attached FWIW)I’ll catch up and have a look, however my suggestions are not important. Those from the user community are. I suggest promotion of the project to attract interested players, asap.LorOn May 19, 2023, at 09:20, Lee @.***> wrote: I've invited Lor to take a look and offer suggestions. Please edit the readme or wiki as you see fit. As soon as we hear from Lor, I agree, we should open it up to the community.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

[tmiw]

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

[tmiw]

I've been doing some testing with pythonnet earlier tonight and it looks pretty promising. For example (with API keys and passwords removed):

test.py:

from pythonnet import load
load("coreclr", runtime_config="./runtimeconfig.json")

import clr
clr.AddReference("WinlinkWebServices")

config = clr.winlink.WinlinkWebServiceConfiguration()
config.WebServiceAccessKey = "XXXXXXX"

clr.winlink.WinlinkWebServices.SetConfiguration(config)
print("Password validation: %s" % (clr.winlink.WinlinkWebServices.ValidatePassword("K6AQ", "XXXXXX")))

runtimeconfig.json:

{
  "runtimeOptions": {
    "tfm": "net7.0",
    "frameworks": [
      {
        "name": "Microsoft.NETCore.App",
        "version": "7.0.0"
      }
    ],
    "configProperties": {
      "System.Reflection.Metadata.MetadataUpdater.IsSupported": false
    }
  }
}

Result:

Mooneer6MBP2461:winlink-mail-client mooneer$ python3 test.py 
Password validation: True
Mooneer6MBP2461:winlink-mail-client mooneer$

Note that WinlinkWebServices.dll and ServiceStack.*.dll were taken from the Paclink source tree, so we'd likely still need a way to build those even if we went with Python or something else for the rest of the codebase. However, this could be a way to get started quickly, with the eventual goal of removing the .NET dependency entirely if we wanted to.

(I bring up Python as an option because I was able to build this webapp pretty quickly recently using the aiohttp and socket.io modules. The source code for it is here if curious.)

[k0qed]

There's no reason why we would need ServiceStack at all. The Winlink web services can easily be consumed using any number of languages. I regularly use just a browser (for API that support GET). Any HTTP client should work just fine.

[tmiw]

There's no reason why we would need ServiceStack at all. The Winlink web services can easily be consumed using any number of languages. I regularly use just a browser (for API that support GET). Any HTTP client should work just fine.

True. I figured since it was already there it could be used to save time during initial prototyping :)

[k0qed]

I think we may want to move this topic forward and decide on a language for the backend. Once that is settled one or more people could work on things like interface modules for the web services, rig control, modem library, etc.

I like C# just because it's the one I'm most familiar with, but I'm open to whatever will work best across the platforms we want to support. Suggestions anyone?

Mooneer - I think you have the broader experience, so I'll defer to you on what you think is best.

[w3qalor]

Just my rough observation, but maybe Python is more popular among the amateur radio community than C# these days. Could be wrong.

—Lor

On Jun 21, 2023, at 1:30 PM, Lee @.***> wrote:

I think we may want to move this topic forward and decide on a language for the backend. Once that is settled one or more people could work on things like interface modules for the web services, rig control, modem library, etc. I like C# just because it's the one I'm most familiar with, but I'm open to whatever will work best across the platforms we want to support. Suggestions anyone? Mooneer - I think you have the broader experience, so I'll defer to you on what you think is best. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[tmiw]

Just my rough observation, but maybe Python is more popular among the amateur radio community than C# these days. Could be wrong. —Lor

FWIW, https://www.tiobe.com/tiobe-index/ seems to confirm your suspicion (though C# is still within the top 5). This is general programming, though, and not specific to amateur radio.

[k0qed]

I was interested to see why python was so popular so I spent some time yesterday and today looking at a couple tutorials. After a bit of a learning cure I was able to produce (the beginnings of) a rather succinct wrapper class for the CMS web service API (no .net). I used the PyCharm IDE from JetBrains, but Visual Studio or Visual Studio Code have support for python as well.

If you want to take a look, the result is on github at: https://github.com/k0qed/cms-api-adapter

There's just a few of the account related API implemented in the account.py file.

[tmiw]

Nice! One thing that would probably be good is to implement async functionality in anything that could involve a wait (such as anything to do with the web services API). This is similar to what would be done in e.g. C#. Perhaps that can be added to a coding standard type document?

Anyway, yeah, let's go with Python for now.

[k0qed]

I used the template at: https://medium.com/code-factory-berlin/github-repository-structure-best-practices-248e6effc405 To create an initial repo file structure and moved the web service API wrapper scripts under the src tree.

[tmiw]

I created #13 so we can figure out the web framework side and will close this issue. Feel free to reopen if more discussion on the backend language is needed.