My Ideas

[jquorning]

These are my thoughts about Yass at the moment:

User experience

• UX Make appealing index.md with colors and a maybe an image
• UX Have CSS on default layout
• UX site.cfg: Have the comments below the parameter and add newline to increase readability
• UX Add favicon.ico

Refactor

• Create Monitors packages. Enables reuse of Save_Exception_Info
• Create Commands packages. Reduce size of Yass main and enables testing
• Refactor yass build and Monitor_Site - They are very alike
• Create_Config and Create_Interactive_Config both creates site.cfg. The latter questions the user in between. This could be replaced by a procedure to ask the user and then a common procedure for writing the site config
• Rename Config to Configuration because of name clash with config/yass_config.ads from alire

Other

• Make page configuration look like yaml surrounded by --- like in Jekyll
• Use CLIC for subcommands.
• --help and --version subcommands for compatibility with many other tools (easy)

[AJ-Ianozi]

One thing I want to mention is that I want to be careful about not breaking backwards-compatibility for version 3. Ideally anything that we do will still be backwards-compatible, but with warnings of deprecation (that's what I'm aiming with moving towards @_ and _@). While it wasn't the case before, I'm aiming to utilize Semantic Versioning for YASS, with the next big dot-upgrade (from 3 to 4) having breaking changes, while most of these improvements coming through I'm hoping to see under 3.2.0. I'd like to see any new way something is done allow being backwards-compatible for at least one update before going away in version 4, if that makes sense.

User experience

Something I appreciate with jekyll is the default website that it generates out of the box. It's pretty slick looking. Would. be nice to have a site that's generated that shows the full features of yass. No argument there. Check out the user documentation to see what's possible with yass that we don't show enough of.

Refactor
Create Monitors packages. Enables reuse of Save_Exception_Info

I don't have a lot to say about the server aspect of yass, I've never used it, so as long as it's working the same way as previous version 3 versions, I don't have any arguments for or against creating a monitors package. If we define any public functions though, we'll want to document the API so robodoc can read it, please just bear that in mind (we technically don't have to if it's within the yass procedure).

Create Commands packages. Reduce size of Yass main and enables testing
Refactor yass build and Monitor_Site - They are very alike

I'm still hesitant to break too much out of the main body of the program, I agree that it can help with unit tests, I just want to make sure it's not getting too complex with the global variables and such. If we go this route, I very much want to make sure that it's doing things identically as the other 3.x.x versions with unit tests to confirm.

I've also mentioned before that the main body of the program is a beast, but it's also fast. I'm looking into re-doing how it's built altogether; version 4 is going to be building indexes of the content for each page, allowing for more dynamic templated pages-- though that's in version 4, and we're not close to being there yet, but I'm hoping to work on that through the summer.

Create_Config and Create_Interactive_Config both creates site.cfg. The latter questions the user in between. This could be replaced by a procedure to ask the user and then a common procedure for writing the site config

This seems fine, I see a PR for it already, I'll be responding to it shortly (work is busy this week, but I'm reading all of the activity on here)

Rename Config to Configuration because of name clash with config/yass_config.ads from alire

If this is done, we'll want to update the Code documentation to reflect it too, but it might as well done sooner than later.

Make page configuration look like yaml surrounded by --- like in Jekyll

I keep going back and forth on what these markdown files should look like. I WISH cmark had a schema for proper comments so it doesn't matter what the header looks like. The current comment system doesn't look great in certain markdown viewers, but neither does --- and I don't really want to use HTML comments.

I mentioned YML a while ago, but if I go that route, I'd want to do so with a proper yml parser that can handle alternate config files and values. We'll want to make sure we can handle things like arrays and such. I feel like this should be something to think about during the redesign.

Use CLIC for subcommands.

I want to avoid adding more libraries if I can. CILC is cool, but I'm worried that it's going to be more overhead than the if-else statement in place right now. We'll probably need better command handling if things get more complex or if we're adding more branching arguments, but I like how blazing fast yass is, it does a lot with some simple work under the hood... but who knows, maybe CILC is doing better than what I'm doing here?

--help and --version subcommands for compatibility with many other tools (easy)

I see no issue with this. I've been thinking about utilizing "help" and "version" to give some more advanced documentation, similar to what alire does, so introducing --help and --version to display the help text and version and exit sounds good.