khanh.pndc/nextcloud-docs
1
0
Fork 0
mirror of https://github.com/nextcloud/documentation.git synced 2026-01-02 17:59:36 +07:00
Code Issues Packages Projects Releases Wiki Activity

fix(developer): clean up grammar and syntax for ExApp installation page

Browse Source 
Signed-off-by: Edward Ly <contact@edward.ly>
This commit is contained in:
Edward Ly
2024-10-30 12:04:09 -07:00
parent 5ea6385ace
commit f62d64eae7
1 changed files with 22 additions and 22 deletions
Download Patch File Download Diff File Expand all files Collapse all files

44
developer_manual/exapp_development/tech_details/InstallationFlow.rst
View File

@@ -3,12 +3,12 @@
App Installation Flow
=====================
Image Pulling(Docker)
---------------------
Image Pulling (Docker)
----------------------
AppAPI **2.5.0+** will always first try to pull a docker image with a ``suffix`` equal to value of *computeDevice*.
Let us remind you that ``computeDevice`` can take the following values: ``cpu``, ``cuda``, ``rocm``
The following values are available for ``computeDevice``: ``cpu``, ``cuda``, or ``rocm``.
The suffix will be added as follows:
@@ -17,22 +17,22 @@ The suffix will be added as follows:
return $imageParams['image_src'] . '/' .
$imageParams['image_name'] . '-' . $daemonConfig['computeDevice']['id'] . ':' . $imageParams['image_tag'];
For ``cpu`` AppAPI will first try to get the image from ``ghcr.io/cloud-py-api/skeleton-cpu:latest``.
For ``cpu``, AppAPI will first try to get the image from ``ghcr.io/cloud-py-api/skeleton-cpu:latest``.
In case the image is not found, ``ghcr.io/cloud-py-api/skeleton:latest`` will be pulled.
If you as an application developer want to have a custom images for any of these values, you can push that extended images to registry in addition to the based one.
If you as an application developer want to have a custom images for any of these values, you can push the extended images to registry in addition to the base one.
Heartbeat
---------
The first thing AppAPI does is deploy of the application.
The first thing AppAPI does is deploy the application.
In the case of ``Docker``, this is:
In the case of Docker, this means:
#. 1. performing an image pull
#. 2. creating container from the docker image
#. 3. if the container supports `healthcheck` - AppAPI waits for the `healthy` status
#. 4. waiting until the “/heartbeat” endpoint becomes available with a ``GET`` request
1. performing an image pull
2. creating container from the docker image
3. if the container supports `healthcheck` - AppAPI waits for the `healthy` status
4. waiting until the “/heartbeat” endpoint becomes available with a ``GET`` request
The application, in response to the request "/heartbeat", should return json: ``{"status": "ok"}``.
@@ -44,15 +44,15 @@ Init
.. note:: Starting from this point, all requests made by AppAPI contains :ref:`auth-headers`.
After application is ready, which is determined by previous step,
AppAPI sends ``POST`` request to the ``/init`` application endpoint.
AppAPI sends a ``POST`` request to the ``/init`` application endpoint.
*If the application does not need to carry out long initialization, it has an option to not implement "/init" endpoint, so
AppAPI will get 404 or 501 error on it's request, and consider that initialization is done and this section can be skipped.*
AppAPI will get 404 or 501 error on it's request, but you can consider that initialization to be done and this section can be skipped.*
In case you want to implement "/init" endpoint, your application should:
1. In "/init" handler: Response with empty JSON on AppAPI call.
2. In background job: Send an ``OCS request`` to ``PUT /ocs/v1.php/apps/app_api/ex-app/status`` with the progress value.
1. In "/init" handler: return a Response with empty JSON data on AppAPI call.
2. In background job: send an OCS request to ``PUT /ocs/v1.php/apps/app_api/ex-app/status`` with the progress value.
.. warning::
@@ -75,7 +75,7 @@ Example of request payload with error will look like this::
Enabled
-------
After receiving **progress: 100** (*or when ExApp is not implementing "/init" endpoint*), AppAPI enables the application.
After receiving **progress: 100** (*or when ExApp is not implementing the "/init" endpoint*), AppAPI enables the application.
To enable or disable the application, a PUT request is sent to the ``/enabled`` endpoint.
@@ -96,17 +96,17 @@ Similarly, to disable the application, the request would be::
This approach ensures that the application's state can be easily toggled using a simple query parameter.
.. note:: ``/enabled`` endpoint shares both **enabling** and **disabling**,
so app should determine what is going on using the ``enabled`` input parameter of the request.
.. note:: The ``/enabled`` endpoint shares both **enabling** and **disabling**,
so the app should determine what is going on using the ``enabled`` input parameter of the request.
Inside ``/enabled`` handler application should register all actions related to the Nextcloud, like UI and all other stuff.
Inside the ``/enabled`` handler, the application should register all actions related to the Nextcloud, such as the UI and other stuff.
Response for this request should contain::
The response for this request should contain::
{"error": ""}
for success and if some error occur during **enabling**, it should be present and not be empty::
for success, and if some error occurs during **enabling**, it should be present and not be empty::
{"error": "i can't handle enabling"}
This is all three steps involved in the applications installation flow.
This is all three steps involved in the ExApp installation flow.