missing features checklist?

[anarcat]

it would be nice to have a list of features missing in pat, when compared to the official winlink software.

i know, for example, pactor is missing (#40) but what else is there? can we run a normal winlink station with Pat or do we still need Wine (e.g. for Winmor) in reality?

is there a roadmap on how to get there?

thanks!

[mathewpeterson]

@anarcat Is there something that is not on http://www.winlink.org/ClientSoftware that you would like to see?

[anarcat]

i guess i was expecting the equivalent of that page somehow here. but if that's kept up to date with latest pat developments, i guess we could just link to it here...

[anarcat]

... and i would have done so myself, but the wiki is not editable somehow.

update: i'd be happy to improve the wiki documentation with my experience if you make it accessible to non-contributors (or make me a contributor :p).

[martinhpedersen]

@anarcat The main purpose of this project is not to be a feature complete alternative to Winlink Express, so I am afraid a list of "missing features" and a roadmap to "get there" may not be in the best interest for this project.

That being said, you are touching a very important topic that we need to address and document clearly; Which features should be included in the first stable release of Pat (v1.0.0)?

I like organizing development tasks in issues and milestones, and have created the milestone/v1.0.0 to track issues that I think we need to address in that release. Maybe we could add a link in the README.md file and name it "The v1 Roadmap" or something?

---

... as for contributing to the wiki, I like the accepted proposal in this stackoverflow question: https://stackoverflow.com/questions/10642928/how-to-pull-request-a-wiki-page-on-github

i know, for example, pactor is missing (#40) but what else is there? can we run a normal winlink station with Pat or do we still need Wine (e.g. for Winmor) in reality?

I guess it depends on how you define a normal winlink station and what OS you are running. Keep in mind, Pat is not a Linux-only application. I guess we could publish some OS specific wiki pages talking about various platform limitations users might need to be aware of.

[anarcat]

The main purpose of this project is not to be a feature complete alternative to Winlink Express, so I am afraid a list of "missing features" and a roadmap to "get there" may not be in the best interest for this project.

well, i understand we may not want to have absolute feature parity, but there's surely a minimum standard to what's required for a winlink host, isn't there? i see, for example, that Pat is one of the few programs that has "RMS Relay support". that seems really promising! the only thing i see are missing from Pat compared to WinLink are:

• Manual "Keyboard" connections
• Message precedence support
• HTML/CSS Forms creation & content-only transport
• Message preview/choose downloads
• Address book
• Packet connection scripting for node/digi navigation
• WL2K Catalog Support (WX and Help bulletins)
• Multi-user
• AGWPE Support
• Multi-language

Now, there's a bunch of those I must admit I have no clue what they do (what the heck is AGWPE and why should i care? isn't that just like soundmodem or direwolf? what's "Manual keyboard connections"? how about "packet connection scripting"?). Others I don't care much (HTML is just bloat). But some of those are really interesting, like multi-user, multi-language and preview support.

i know, for example, pactor is missing (#40) but what else is there? can we run a normal winlink station with Pat or do we still need Wine (e.g. for Winmor) in reality?

I guess it depends on how you define a normal winlink station and what OS you are running. Keep in mind, Pat is not a Linux-only application. I guess we could publish some OS specific wiki pages talking about various platform limitations users might need to be aware of.

Sure, I understand that Pat can call winmor directly in Windows. I guess my question here is broader than just pat: what's the baseline for a winlink node? i have pat running over telnet, am i in or do I need a VHF link? or HF? AX-25 sufficient? or should i force myself to implement winmor in go? :)

It would certainly be interesting to see a Pat-specific "feature vs OS" grid that would show what works and what doesn't and how (e.g. "Winmor + linux = yes, through WINE").

That being said, you are touching a very important topic that we need to address and document clearly; Which features should be included in the first stable release of Pat (v1.0.0)?

I like organizing development tasks in issues and milestones, and have created the milestone/v1.0.0 to track issues that I think we need to address in that release. Maybe we could add a link in the README.md file and name it "The v1 Roadmap" or something?

That's a great idea!

Should I explicitly file issues about some of those I would like to see so you can triage them explicitly or how do you want to do this? :)

... as for contributing to the wiki, I like the accepted proposal in this stackoverflow question: https://stackoverflow.com/questions/10642928/how-to-pull-request-a-wiki-page-on-github

okay, I opened #94 to followup on that discussion.

thanks so much for taking the time to reply, i really appreciate your openness on this.

[martinhpedersen]

It would certainly be interesting to see a Pat-specific "feature vs OS" grid that would show what works and what doesn't and how (e.g. "Winmor + linux = yes, through WINE").

I really like this idea. It could serve as a clear way to communicate to potentially new users what they can expect at this stage, before investing their time and digging in to the details.

That's a great idea!

Should I explicitly file issues about some of those I would like to see so you can triage them explicitly or how do you want to do this? :)

I am tempted to suggest that we first discuss new features in the pat-users mailing list, and then escalate it as an issue on GitHub when the terms are set. But maybe we should skip that for now, and just see how it works out. The downside is that we may have to be "harsh" and close some requests quickly in order to keep the list open issues to a manageable size. What do you think?

But yes - please go ahead and open issues for the missing features (at least the obvious ones), and I will triage them accordingly.

PS: I think you are raising a lot of important questions regarding contributions and collaboration, and I very much appreciate your involvement. Thank you!

[anarcat]

I am tempted to suggest that we first discuss new features in the pat-users mailing list, and then escalate it as an issue on GitHub when the terms are set. But maybe we should skip that for now, and just see how it works out. The downside is that we may have to be "harsh" and close some requests quickly in order to keep the list open issues to a manageable size. What do you think?

I'm fine with that - I can't stand mailing lists anymore :p

But yes - please go ahead and open issues for the missing features (at least the obvious ones), and I will triage them accordingly.

awesome, will do.

PS: I think you are raising a lot of important questions regarding contributions and collaboration, and I very much appreciate your involvement. Thank you!

thanks, that means a lot!

[martinhpedersen]

AFAIK, I kept this issue open as a reminder to re-evaluate the (rather strict) wiki write-access policy. I've now decided to open up for public write access. Let's try it out for some time, and see how it goes.

I believe the initial request (include a missing features list) was fulfilled by adding a link to Winlink's Client Software comparison page in our wiki. So I guess it's time to close this issue.

Please don't hesitate to re-open if I left something unresolved.

[W1RPQ]

Very new to this but I do see the address book as a very important tool for Pat-winlink. For ARES use it would really help in speeding up message sending.