Web simulator documentation and examples missing.

[janiversen]

The new web simulator misses some features, before being the main simulator:

• ReST API
• Documentation
• trace of calls.

Documentation of config done ! Documentation of web pages waits until (someone) the have a better look. Documentation of http_server and main can be done.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[efdx]

Hello,

I am currently contemplating on possibilities for automating use of the client. The ReST-API would be a convenience for me, and I could possibly create a skeleton for the buildjson* functions based on their html equivalents. But what kind of state would you expect for it at this point? At best, they would be filled, but I don't think I have the know-how/time to set up full integration tests for whatever I would do, much less fully document it.

So in short: if anything is done, what is the expected outcome?

[janiversen]

I am not sure how you can make a rest api without fully integrating it.

This might b3 easier if you submit a pull request, allowing us to review it.

Ps. the pull request do not need to be "everything" but enough that we can see the direction is sound.

[janiversen]

Documentation is of course important, without it the feature is unknown, however writing documentation is easier than programming skeletons, just have a look in docs

[efdx]

I am not sure how you can make a rest api without fully integrating it.

Yeah true, I guess it could not be called that :D What I meant is that if I take build_html_registers and convert on build_json_registers (more or less copy-paste + adapt at this point), I would get enough to manipulate registers with json format API. This indeed would not be a full API in any sense. Plus as said, I don't know enough of the features included in build_html_registers (mainly operations, Set, Clear, Stop, etc) to validate if they function properly or not. Due to these, I'd still call it a skeleton at best.

Same would apply for the other json endpoints.

If I had time, I do have plans on how to implement it completely. Sadly, I'm lacking on the extra-time department :/

Documentation is of course important

Of course. But in my case, the same skeleton principle would apply. It would only be something like

ReST API Title
==============

Note. This is still a work in progress. Here is the current description of calls supported at the moment.

<insert-content-here>

But regardless. I'll see what I can do about the PR. No promises though.