axiscommunications / acap-documentation Goto Github PK

When reading Create a manifest file from scratch we reference the simple Hello Glib ACAP application. What is that? Is than an existing sample in acap-native-sdk-examples or acap-computer-vision-sdk-examples?

I don't think the reader at this point is familiar with the application, and if we cant add a link to the application I think we should remove the reference.

On Application project structure - Create a manifest file from scratch in bullet 2 we describe the running mode as the application keeps running at a reboot, but looking at the code sample we use the value never which according to the manifest description means that the application will never be restarted.

This doesn't add up. One of the descriptions is wrong.

The name of the default branch is master. We ought to discuss the pros and cons for keeping this name in favour of main.

The following arguments are opposed to naming the default branch master.

• Inclusiveness
• This is a new project, thus I assumed the default branch to be main
• With time, the name master will be used more seldom. New project will be created with the name main and many old project will probably migrate to the new name main

The following arguments are favouring the default branch master.

• Most developers today will recognise the name master, but an argument can be made that this will transition to be false given time
• Given you're using links to reference specific parts of this repository from parts of the internet, the risks are high that the default branch name is part of these links.

The files schema-field-descriptions-* are auto-generated from an upstream source. As a contributor this is not obvious.

Action points:

• It should be obvious that these files have been autogenerated. I should be able to read this in the specific Markdown documents.
• Let's update the contributing guidelines with information regarding auto-generated content. As a contributor, what should I look for to determine whether content has been auto-generated or not.
• Let's update the specific Markdown documents regarding their upstream source, if I cannot make changes in the auto-generated content, where should I make the changes?

We have gotten the feedback that we ought to state in the documentation that applications built using older SDKs cannot be signed in the ACAP portal. This is relevant for ACAP3 SDK versions below 3.5 and Native SDK versions below 1.1.

The reason for this is that the portal requires "architecture" to be included in the manifest, and support for that did not exist in earlier SDKs.

Do the runtime credentials also give us access to the RTSP server? Have not yet tested this, if not then please add this. Otherwise we still need to ask clients to enter a username/password upon app installation on the camera. This is an inconvenience which lowers adoption and long term stability of the app. Our app uses the local RTSP server and for the sake of efficiency we do not want to duplicate this functionality inside our app.

Thank you.

In Azure there's a concept called ARM which basically are JSON files that describe infrastructure. Here you can see how they are documented.

In AWS there's a concept called CloudFormation which, again, basically are JSON files that describe infrastructure. Here you can see how they are documented.

One cannot help but to identify the similarities. They both start with a JSON document that highlight the structure, and then below the document each property is described, together with its type and whether it is required.

As the saying goes: good artists borrow, great artists steal.

Hi,

Why are we referring to 2 different versions tracks in our official ACAP Native SDK documentation, i.e. version 1.x track and version 4.x track?

This just causes confusion, why not only refer to 4.x versions in all places?

See this page:

https://axiscommunications.github.io/acap-documentation/docs/api/native-sdk-api.html#compatibility

Compatibility

The table below shows ACAP Native SDK and firmware version compatibility.

....and compare it to this one:

https://axiscommunications.github.io/acap-documentation/docs/axis-devices-and-compatibility/#find-the-right-sdk-for-software-compatibility

Find the right SDK for software compatibility

Choose the appropriate SDK version based on what AXIS OS version you want supporting your ACAP.

Is there any particular benefit of mentioning 1.x versions at all?

The following idea came after reading Manifest schemas.

Many text editors and IDE:s today have either built in, or can be extended with, support for validating JSON files against a JSON schema. Validating the manifest, given its version, before running the actual build would improve the feedback loop, which is nice.

I would be open to contribute the JSON schemas, given that we decide where they should be published. One alternative would be to publish them on JSON Schema Store, another would be to self-host it them one of our repositories. Each alternative has pros and cons.

I cannot find markdownlint being run for the markdown files in the GitHub pipeline, am I missing something or is it indeed missing?

On Set up device - Find the device on the network we propose tools that only work on Windows. These tools are really good at what they do, but I think there's room for an officially supported cross platform device discovery tool that we can use on Linux and macOS.

Preferably it would be a discovery tool that adhere to the Linux principles, letting you pipe results and stuff like that, making it easy to integrate the tool into any pipeline you build.

And taking a stand here, it would be much better if this tool was written in Go, published as open source, and maintained in this Axis organization.

In the table describing the manifest file content, there's a reference attached to the parameter called acapPackageConf.setup.embeddedSdkVersion. The reference is assumed to be found under the table, but is instead found at the end of the document, under a chapter called Local data.

https://axiscommunications.github.io/acap-documentation/docs/api/cv-api.html#video-capture-api
Axis VDO library
points to https://axiscommunications.github.io/acap-documentation/docs/api/3.4/api/vdostream/html/index.html