Contact Details (optional)

No response

Background

DME Core should be able to automatically load (for example at boot time) all the DME Suite components a user has requested to autoload.

The Autoloader should possibly be multi-tasking (or multi-tasking as much as possible on RISC OS).

The autoloader should follow the logic discussed here: #12

For more info on the overall architecture of the DME Core please check out the Wiki here: https://github.com/RISC-OS-Community/DME-Core/wiki/DME-Core

Definition of Done

• An accepted (and discussed) protocol for the "components-to-launch at boot" is defined
• DME Core is able to read a "components-to-launch at boot" configuration file(s) and process it/them
• Launch such components in the order and with the requisites expressed in their configuration, possibly in multi-tasking
• Provide tests cases to verify the feature
• Both User Documentation and Developer Documentation is written
• Code passes all test cases

Code of Conduct

• I agree to follow this project's Code of Conduct

Background

@RISC-OS-Community/code-reviews-team
Given that DME is something we are creating for end-users of all level of experience on RISC OS, do we think it may be beneficial to introduce a "layer" of formal testing within the RISC OS Community before we release the code for a broader audience to test and report?

Definition of Done

• Idea proposed
• Idea being discussed
• We have reached a conclusion

Background

This is just a test

Definition of Done

• Created a task
• Processing a task
• Completed task

Contact Details (optional)

No response

Background

@RISC-OS-Community/code-reviews-team / @RISC-OS-Community/docs-team ,
If someone has time, could you please review and correct the new Wiki Home for the DME Project?

link here: https://github.com/RISC-OS-Community/DME-Core/wiki

Thanks!

Definition of Done

• Task A is done when. the wiki page is reviewed :)

Code of Conduct

• I agree to follow this project's Code of Conduct

Background

The whole DME Engine will require some Configuration Framework capable of handling multiple tools with a consistent UI.
Before we start thinking of designing one, I think it would be good to have a look at whatever is already available for RISC OS.

So my proposal is to have a look at ConfiX (and its API) to understand if it's the right tool to use to configure the whole DME tools.

What we need is a graphic tool capable of generating a configuration file for each piece we'll develop add. It's not important if it can configure everything using a single instance of itself. I think it's probably better to have multiple instance one per each tool. However it's important it provides a consistent experience for a user (especially for new users).

I don't think we need to contact the Author given that the tool is available for free download and use and the author is invested in the RISC OS world. The tool was original recommended by Andrew R. from ROD. However we may want to verify that we are not violating the distribution license and that it could be used in ROOL if ROOL wants to tae the code from this repo.

Definition of Done

• Task proposed
• ConfiX being investigated and API tested
• We have reached a decision about it

Background

@RISC-OS-Community/code-reviews-team , not urgent, but we may want to have a chat about this.

I have been working on a RISC OS Module that would allow Obey scripts to be able to talk with RESTFul APIs like the one offered by github. I still need to finish it and also add a module that would embed JSONC features to allow Obey to be able to use JSON content (either process or generate).

Anyway when the above would be completed we could have a look at the github API to see we we could integrate with their CI/CD infrastructure so to have reports of a build on here.

Definition of Done

• Proposed the idea for discussion
• The idea is being discussed
• We have reached a conclusion