Skip to content

Conversation

@ve7fet
Copy link
Collaborator

@ve7fet ve7fet commented Apr 10, 2025

Remove remote base and DAQ config options that are rarely used (remote base) or currently unsupported (DAQ), and are just adding clutter and confusion to rpt.conf.

ASL manual will document all the available config options and their usage, should users want/need to enable those options.

This cleans up the default template for new users.

Remove remote base and DAQ config options that are rarely used (remote base) or currently unsupported (DAQ), and are just adding clutter and confusion to rpt.conf.

ASL manual will document all the available config options and their usage, should users want/need to enable those options.

This cleans up the default template for new users.
@InterLinked1
Copy link
Member

Since there are already comments for these, these should be moved to the sample file (which doesn't exist yet) before being removed

@mkmer
Copy link
Collaborator

mkmer commented Apr 10, 2025

Thinking out loud: would it make sense to group uncommon "stuff" together with a comment about it being uncommon?
OR maybe have a rpt.conf.all file that has every option available in it, and a rpt.conf with most common?
I suppose that's what the manual is for - once we have it all in there.

@Allan-N
Copy link
Collaborator

Allan-N commented Apr 10, 2025

We could also move the uncommon "stuff" into one or more #include files.

@InterLinked1
Copy link
Member

Thinking out loud: would it make sense to group uncommon "stuff" together with a comment about it being uncommon? OR maybe have a rpt.conf.all file that has every option available in it, and a rpt.conf with most common?

The sample file is the one with every option in it.

@Allan-N
Copy link
Collaborator

Allan-N commented Apr 10, 2025

... and the plan is to add documentation to the code and then generate the sample files (with everything documented) using https://github.com/InterLinked1/astsamplegen

@ve7fet
Copy link
Collaborator Author

ve7fet commented Apr 10, 2025

Since there are already comments for these, these should be moved to the sample file (which doesn't exist yet) before being removed

I have commented pretty much every option I have found (so far) in the pending rpt.conf PR that is going into the manual. There are a few "undocumented" ones I still need to track down. I've gone through all the existing rpt.conf examples floating around, and tried to capture all the settings to get them all documented.

My thoughts on this PR is that for the majority of users, there are options in the installed sample rpt.conf that they will never use (remote base stuff) or aren't even currently supported (DAQ... I have an idea on how to support that in the future though). So, for readability purposes, I feel it makes sense to get rid of the clutter, and only include the options that they must have to make a functioning system, or are likely to want to customize.

In addition, some of the stuff, like the [remote-functions], is unreachable. Unless you specifically name that stanza in the node config to pull it in, it is orphaned, and will be ignored.

As I work through building more manual pages, my intent is to include sample code blocks of configs that can be added to the user's rpt.conf to enable those features... but that will be a work in progress, and will take a number of iterations, until everything is in the manual, and all the cross-references are added.

@ve7fet
Copy link
Collaborator Author

ve7fet commented Apr 10, 2025

We could also move the uncommon "stuff" into one or more #include files.

That's probably a decent way to manage some of the more uncommon features. It would keep some of the clutter out of the main rpt.conf file, and group the related/required settings for the option into one place.

@InterLinked1
Copy link
Member

... and the plan is to add documentation to the code and then generate the sample files (with everything documented) using https://github.com/InterLinked1/astsamplegen

This is still sort of a proof of concept... not sure if the tool is that mature yet.
Either way, the documentation the OP is proposing to remove would need to be documented. Right now, there is no documentation and no sample.

@ve7fet
Copy link
Collaborator Author

ve7fet commented Apr 10, 2025

... and the plan is to add documentation to the code and then generate the sample files (with everything documented) using https://github.com/InterLinked1/astsamplegen

This is still sort of a proof of concept... not sure if the tool is that mature yet. Either way, the documentation the OP is proposing to remove would need to be documented. Right now, there is no documentation and no sample.

See:
AllStarLink/ASL3-Manual#109
AllStarLink/ASL3-Manual#110
AllStarLink/ASL3-Manual#111

@InterLinked1
Copy link
Member

... and the plan is to add documentation to the code and then generate the sample files (with everything documented) using https://github.com/InterLinked1/astsamplegen

This is still sort of a proof of concept... not sure if the tool is that mature yet. Either way, the documentation the OP is proposing to remove would need to be documented. Right now, there is no documentation and no sample.

See: AllStarLink/ASL3-Manual#109 AllStarLink/ASL3-Manual#110 AllStarLink/ASL3-Manual#111

I'm talking about XML documentation in the code, not any external documentation that may exist elsewhere. For the purposes of this repo, that doesn't count.

@ve7fet
Copy link
Collaborator Author

ve7fet commented Apr 10, 2025

I'm talking about XML documentation in the code, not any external documentation that may exist elsewhere. For the purposes of this repo, that doesn't count.

Can you point to this XML documentation you refer to? I must not be looking in the right place.

Regarding sample docs... sure I can write some samples to put in, and add some includes to pull the samples in to rpt.conf.

@InterLinked1
Copy link
Member

I'm talking about XML documentation in the code, not any external documentation that may exist elsewhere. For the purposes of this repo, that doesn't count.

Can you point to this XML documentation you refer to? I must not be looking in the right place.

That's just it, there isn't any currently for any of the radio modules, it's part of the backlog to add some so that all the options are documented there.
The CLI documentation, auto-generated Asterisk web docs, etc. all stem from the XML documentation.

Here is an example of a module that has documentation: https://github.com/asterisk/asterisk/blob/master/apps/confbridge/conf_config_parser.c#L44

Regarding sample docs... sure I can write some samples to put in, and add some includes to pull the samples in to rpt.conf.

I think Allan wants to experiment with not working on samples for the moment to see if we can autogenerate them. If somebody wants to do that, that's certainly great, but I think the XML documentation alone will probably be more valuable right now.

@Allan-N
Copy link
Collaborator

Allan-N commented Apr 10, 2025

I think Allan wants to experiment with not working on samples for the moment to see if we can autogenerate them. If somebody wants to do that, that's certainly great, but I think the XML documentation alone will probably be more valuable right now.

Correct. We can spend our time updating the .conf files, adding .sample files, adding comments into the code, and updating all of the above whenever changes to be needed. Or, we can focus our efforts. By adding the XML documentation (into the code) we can use tools to create/update all of the other content. That also puts the truth in one place.

@ve7fet
Copy link
Collaborator Author

ve7fet commented Apr 11, 2025

I think Allan wants to experiment with not working on samples for the moment to see if we can autogenerate them. If somebody wants to do that, that's certainly great, but I think the XML documentation alone will probably be more valuable right now.

Correct. We can spend our time updating the .conf files, adding .sample files, adding comments into the code, and updating all of the above whenever changes to be needed. Or, we can focus our efforts. By adding the XML documentation (into the code) we can use tools to create/update all of the other content. That also puts the truth in one place.

Ok, I can have a look and see if I can help with some of the XML documentation... once I finish working on the ASL3 manual conversions I'm working on.

In regards to this PR. I've moved the removed settings to sample files, and adjusted rpt.conf to pull in the additional conf files for those features.

@InterLinked1
Copy link
Member

I think Allan wants to experiment with not working on samples for the moment to see if we can autogenerate them. If somebody wants to do that, that's certainly great, but I think the XML documentation alone will probably be more valuable right now.

Correct. We can spend our time updating the .conf files, adding .sample files, adding comments into the code, and updating all of the above whenever changes to be needed. Or, we can focus our efforts. By adding the XML documentation (into the code) we can use tools to create/update all of the other content. That also puts the truth in one place.

Ok, I can have a look and see if I can help with some of the XML documentation... once I finish working on the ASL3 manual conversions I'm working on.

In regards to this PR. I've moved the removed settings to sample files, and adjusted rpt.conf to pull in the additional conf files for those features.

The sample configs aren't quite right... there should only be one rpt.conf.sample, and no "subfiles" for components of that. Samples also usually don't have templates.
If this is just temporary and you plan to remove those / replace with the documentation soon, I'm not as concerned.

@mkmer
Copy link
Collaborator

mkmer commented Nov 24, 2025

@Allan-N do we want this one resolved and merged or is it dead at this point?

@InterLinked1
Copy link
Member

@Allan-N do we want this one resolved and merged or is it dead at this point?

Documentation should not be deleted. Since the rpt version has the only documentation for certain things currently, any removed items need to go either in the sample config or the XML documentation. If those are done, then I think that would unblock this change.

@Allan-N
Copy link
Collaborator

Allan-N commented Nov 24, 2025

I really don't want to close this PR. I also don't think it's ready to be merged.

Long term, we should be updating the code with all of the variables, defaults values, descriptions, etc and then use that to generate / update the online documentation, sample files, etc. But, I don't see us doing that with this PR.

For this PR, I think the question is whether we want to extract out the uncommon (blocks of) options into separate #include/#tryinclude .conf files.

@ve7fet
Copy link
Collaborator Author

ve7fet commented Nov 25, 2025

I really don't want to close this PR. I also don't think it's ready to be merged.

Long term, we should be updating the code with all of the variables, defaults values, descriptions, etc and then use that to generate / update the online documentation, sample files, etc. But, I don't see us doing that with this PR.

For this PR, I think the question is whether we want to extract out the uncommon (blocks of) options into separate #include/#tryinclude .conf files.

The goal is/was to try and clean up rpt.conf by removing "clutter" for options that are rarely (if ever) used. Case in point are the DAQ configs. I don't know if there is a single user out there with the compatible hardware to use those options, so for the majority of all users, it is just "noise" in the config file (which is complex enough as it is).

What's the best path forward? I don't know. But Allan's suggestion of hiving some of this off into something like a rpt_daq.conf and using an #tryinclude might be a compromise that would help? That would get it out of the main rpt.conf to help clean things up. And if someone went and deleted the extra files, it wouldn't make Asterisk mad.

@InterLinked1
Copy link
Member

What's the best path forward? I don't know. But Allan's suggestion of hiving some of this off into something like a rpt_daq.conf and using an #tryinclude might be a compromise that would help? That would get it out of the main rpt.conf to help clean things up. And if someone went and deleted the extra files, it wouldn't make Asterisk mad.

The proper solution is they are all in the sample config, but that doesn't currently exist.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants