Task state acquisition method and device, electronic equipment and storage medium

Abstract

The invention discloses a task state acquisition method and device, electronic equipment and a storage medium, and relates to the technical field of information. The task state acquisition method is applied to a service thread running on a client, the client comprises a browser, and the browser is used for displaying a page of a front-end application of a cloud service platform. The task state acquisition method comprises the following steps: acquiring a state acquisition instruction corresponding to a target asynchronous task, wherein the target asynchronous task is an asynchronous task executed by a cloud service platform indicated by a front-end application; and sending a state acquisition request to the cloud service platform according to the state acquisition instruction. The state acquisition request is used for indicating the cloud service platform to return state information of the target asynchronous task. And receiving state information of the target asynchronous task returned by the cloud service platform. According to the method, the client can still obtain the state information of the target asynchronous task as required even if the user leaves the page of the front-end application.

Description

Technical Field

[0001] This application relates to the field of information technology, and in particular to a method, apparatus, electronic device, and storage medium for acquiring task status. Background Technology

[0002] The most common user scenario on cloud service platforms is initiating asynchronous tasks from the platform's front-end application to the back-end. These asynchronous tasks often take some time to complete in the background. Due to the uncertainty of task execution time, it is necessary to obtain the task status of the asynchronous tasks through the front-end application interface.

[0003] To enable the front-end application interface to obtain the task status of asynchronous background tasks, a method for obtaining the asynchronous task status has been proposed. This method involves setting a timer in the front-end application's JavaScript code. At regular intervals, the front-end application sends a network request to the back-end, waits for the request to return, and then obtains the task status of the asynchronous background task. However, this method only works when the user is on the front-end application interface; the task status cannot be obtained after the user leaves the front-end application interface. Summary of the Invention

[0004] The purpose of this application is to provide a method, apparatus, electronic device, and storage medium for obtaining task status, so that the client can still obtain the status information of the target asynchronous task as needed even when the user leaves the front-end application page.

[0005] To achieve the above objectives, the embodiments of this application provide the following solutions:

[0006] Firstly, this application provides a method for obtaining task status, applied to a service thread running on a client, the client including a browser, the browser being used to display the page of a front-end application of a cloud service platform; the method includes: obtaining a status acquisition instruction corresponding to a target asynchronous task, the target asynchronous task being an asynchronous task instructed by the front-end application to be executed by the cloud service platform; sending a status acquisition request to the cloud service platform according to the status acquisition instruction; the status acquisition request being used to instruct the cloud service platform to return status information of the target asynchronous task; and receiving the status information of the target asynchronous task returned by the cloud service platform.

[0007] By using a service thread on the client-side front-end application that is independent of the cloud service platform, a status retrieval request is sent to the cloud service platform, and the status information of the target asynchronous task returned by the cloud service platform is received. This avoids the interruption of obtaining the status information of the asynchronous task when the user leaves the front-end application page of the cloud service platform, so that the client can still obtain the status information of the target asynchronous task as needed even when the user leaves the front-end application page.

[0008] In one possible implementation, sending a status acquisition request to the cloud service platform according to the status acquisition instruction includes: sending a status acquisition request to the cloud service platform once every preset time interval according to the status acquisition instruction, until the preset polling termination condition is met.

[0009] The service thread polls the cloud service platform at preset time intervals to obtain the status information of asynchronous tasks, such as sending a status retrieval request to the cloud service platform every 5 minutes to inquire about the status of the target asynchronous task. This timely and automatic acquisition of the target asynchronous task's status information effectively achieves continuous monitoring of the target asynchronous task. Therefore, even when the user leaves the front-end application page, the client can still know the status of the target asynchronous task in a timely manner. At the same time, preset polling termination conditions limit the stopping conditions of status retrieval requests, avoiding indefinite polling requests, improving the operational stability of the service thread and the cloud service platform, reducing system resource consumption, and also reducing client power consumption.

[0010] In one possible implementation, the preset polling termination condition includes: the most recently received status information indicating that the target asynchronous task has been completed. Thus, if the target asynchronous task has been completed, the service thread will no longer send status retrieval requests to the cloud service platform, avoiding invalid query requests to the cloud service platform.

[0011] In one possible implementation, after receiving the status information of the target asynchronous task returned by the cloud service platform, the process further includes: pushing a notification message to the browser, whereby the notification message indicates the task status of the target asynchronous task. In this way, if the target asynchronous task has been completed, the service thread will no longer send status retrieval requests to the cloud service platform, avoiding invalid query requests to the cloud service platform.

[0012] In one possible implementation, the browser displays a notification message on its currently displayed page even when the front-end application is closed. This way, the user can still receive the notification through the browser's currently displayed page even after closing the front-end application.

[0013] In one possible implementation, obtaining the status acquisition instruction corresponding to the target asynchronous task includes receiving the status acquisition instruction for the target asynchronous task sent by the front-end application. In this way, the front-end application proactively instructs the service thread to obtain the current status information of the specified asynchronous task according to its needs, and the service thread obtains the current status information of the asynchronous task based on the instruction from the front-end application, which better meets the needs of the front-end application.

[0014] In one possible implementation, the front-end application includes a target method. This target method responds to a triggering operation of a target asynchronous task in the front-end application, instructing the cloud service platform to execute the target asynchronous task. The target method is configured with a decorator. The decorator sends a status retrieval instruction corresponding to the target asynchronous task to the service thread after the target method is invoked. The triggering operation is the action that initiates the target asynchronous task (e.g., clicking a button to start the asynchronous task).

[0015] By configuring a decorator in the target method of the front-end application, a status retrieval command can be automatically sent to the service thread after the user triggers the target asynchronous task of the front-end application, so as to instruct the service thread to retrieve the status information of the target asynchronous task.

[0016] In one possible implementation, the decorator is also used to obtain the request information corresponding to the target asynchronous task returned by the cloud service platform after the target method is invoked, and, if the request information is obtained, to determine the status retrieval instruction containing the request information; the request information is used by the service thread to generate a status retrieval request. In this way, obtaining the request information through the decorator and determining the status retrieval instruction containing the request information increases the extensibility and maintainability of the code.

[0017] In one possible implementation, the service thread includes a polling queue to store status retrieval instructions for asynchronous tasks; a decorator is used to register the status retrieval instructions for the target asynchronous task into the polling queue. In this way, after the target asynchronous task is triggered, the front-end application automatically registers the status retrieval instructions into the polling queue, enabling the service thread to automatically and continuously query the status information of each target asynchronous task without requiring manual code to handle this process.

[0018] Secondly, this application provides another method for obtaining task status, applied to a client, which includes a browser for displaying the front-end application page of a cloud service platform, and also includes a service thread. The method includes: the front-end application responding to a triggering operation of a target asynchronous task by sending a status acquisition instruction corresponding to the target asynchronous task to the service thread; the target asynchronous task being an asynchronous task instructed by the front-end application to be executed by the cloud service platform; the service thread acquiring the status acquisition instruction corresponding to the target asynchronous task; the service thread sending a status acquisition request to the cloud service platform according to the status acquisition instruction; the status acquisition request instructing the cloud service platform to return status information of the target asynchronous task; and the service thread receiving the status information of the target asynchronous task returned by the cloud service platform.

[0019] By collaborating between the front-end application and the service thread, the client can obtain the status information of asynchronous tasks in real time, automatically and accurately, thereby improving user satisfaction and optimizing resource utilization.

[0020] In one possible implementation, before the front-end application responds to the triggering operation of the target asynchronous task and sends the status retrieval instruction corresponding to the target asynchronous task to the service thread, it also includes: registering the service thread in response to the startup of the front-end application. In this way, the registered service thread communicates between the cloud service platform and the client on behalf of the front-end application. Since the service thread can run independently in the browser, the client can still receive the status information of the target asynchronous task even when the user leaves the front-end application's page.

[0021] Thirdly, this application provides another method for obtaining task status, applied to a cloud service system, which includes a client and a cloud service platform; the client includes a browser and a service thread, the browser being used to display the front-end application page of the cloud service platform; the method includes: the front-end application responding to a triggering operation of a target asynchronous task by sending a status acquisition instruction corresponding to the target asynchronous task to the service thread, the target asynchronous task being an asynchronous task instructed by the front-end application to be executed by the cloud service platform; the service thread acquiring the status acquisition instruction corresponding to the target asynchronous task; the service thread sending a status acquisition request to the cloud service platform according to the status acquisition instruction; the status acquisition request instructing the cloud service platform to return status information of the target asynchronous task; the cloud service platform responding to the status acquisition request by returning the status information of the target asynchronous task to the service thread; and the service thread receiving the status information of the target asynchronous task returned by the cloud service platform.

[0022] By collaborating between the front-end application, service threads, and the cloud service platform, the client can obtain real-time, automatic, and accurate status information of asynchronous tasks executed by the cloud service platform. Specifically, a service thread interacts directly with the cloud service platform, replacing the front-end application. The cloud service platform sends the status information of the target asynchronous task to the service thread. This approach minimizes the need to modify the client by setting up a service thread, reduces reliance on servers (such as API servers), and ensures that the client can still obtain the status information of the target asynchronous task on demand, even when the user leaves the front-end application page of the cloud service platform. Furthermore, it improves the performance and scalability of the cloud service system.

[0023] Fourthly, this application provides a task status acquisition device applied to a client, the client including a browser, the browser being used to display the page of a front-end application of a cloud service platform; the device includes: an acquisition module, used to acquire a status acquisition instruction corresponding to a target asynchronous task, the target asynchronous task being an asynchronous task instructed by the front-end application to be executed by the cloud service platform; a sending module, used to send a status acquisition request to the cloud service platform according to the status acquisition instruction; the status acquisition request being used to instruct the cloud service platform to return status information of the target asynchronous task; and a receiving module, used to receive the status information of the target asynchronous task returned by the cloud service platform.

[0024] This task status acquisition device avoids interruptions in obtaining asynchronous task status information when the user leaves the front-end application page of the cloud service platform, ensuring that the client can still obtain the status information of the target asynchronous task as needed even when the user leaves the front-end application page.

[0025] Fifthly, this application provides an electronic device, including: a processor and a memory for storing processor-executable instructions; when the processor is configured to execute instructions, the electronic device implements the task state acquisition method described above.

[0026] Sixthly, this application provides a storage medium storing computer program instructions thereon; when the computer program instructions are executed by an electronic device, the electronic device performs the task state acquisition method as described above. Attached Figure Description

[0027] Figure 1 This is a schematic diagram of the structure of a cloud service system provided in an embodiment of this application;

[0028] Figure 2 A flowchart illustrating a task status acquisition method provided in an embodiment of this application;

[0029] Figure 3 A flowchart illustrating a method for sending a status acquisition instruction containing request information to a service thread, as provided in an embodiment of this application;

[0030] Figure 4 A flowchart illustrating another task status acquisition method provided in this application embodiment;

[0031] Figure 5 A flowchart illustrating another task status acquisition method provided in this application embodiment;

[0032] Figure 6 This is a schematic diagram of the structure of a task status acquisition device provided in an embodiment of this application;

[0033] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0034] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. "And / or" in this document is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone.

[0035] In the following description of the embodiments of this application, unless otherwise stated, "a plurality of" means two or more.

[0036] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0037] The following is a brief introduction to the relevant terms used in the embodiments of this application.

[0038] Asynchronous tasks: Asynchronous tasks refer to tasks that are triggered by the user through the front-end application of the cloud service platform, started and executed by the cloud service platform, and completed after a period of time.

[0039] Service worker: In this embodiment of the application, unless otherwise specified, it is a script that runs in the background of the browser. It can run continuously outside the page lifecycle of the front-end application of the cloud service platform, even if the page of the front-end application of the cloud service platform is closed.

[0040] The following provides an exemplary description of the application scenarios of the embodiments of this application.

[0041] Currently, users initiate asynchronous tasks to the cloud service platform through the platform's front-end application. These asynchronous tasks often need to be executed in the background for a period of time before they are completed.

[0042] Taking the asynchronous task of restarting a database instance as an example, a user enters a restart command on the front-end application's page through their browser. The front-end application initiates the database instance restart by sending a Hypertext Transfer Protocol (HTTP) request to the cloud service platform. Upon receiving the HTTP request, the cloud service platform sends a restart command to the machine hosting the database instance, executing the restart task. After waiting a few minutes, the user refreshes the browser's front-end application page, allowing the front-end application to obtain the current status information of this asynchronous task on the cloud service platform. However, during these few minutes, the user may leave the front-end application page to do other things. This interruption of real-time communication between the front-end application and the cloud service platform prevents the client's front-end application from obtaining the current status information of the asynchronous task on the cloud service platform. Consequently, the client cannot display this current status information to the user.

[0043] For example, a user leaving the front-end application page includes the following situations: closing the front-end application page while the browser is open, switching to another page displayed in the browser, minimizing the browser window, or closing the browser. In all of these situations, the client's front-end application will be unable to obtain the current status information of the asynchronous task on the cloud service platform.

[0044] In view of this, this application provides a method for obtaining task status. The method obtains the status information of the target asynchronous task from the cloud service platform through a service thread of a front-end application on the client that is independent of the cloud service platform. Even if the user leaves the front-end application page of the cloud service platform, the client can still receive the status information of the target asynchronous task.

[0045] In some embodiments, the method provided in this application is applied to a client and executed by a service thread running on the client. First, the service thread obtains a status retrieval instruction corresponding to the target asynchronous task. Based on the status retrieval instruction, the service thread sends a status retrieval request to the cloud service platform. The service thread receives the status information of the target asynchronous task returned by the cloud service platform. Here, the target asynchronous task is an asynchronous task instructed by the front-end application to be executed by the cloud service platform. The status retrieval request is used to instruct the cloud service platform to return the status information of the target asynchronous task.

[0046] In this embodiment, a service thread of a front-end application on the client, independent of the cloud service platform, sends a status acquisition request to the cloud service platform and receives the status information of the target asynchronous task returned by the cloud service platform. This avoids the interruption of obtaining the status information of the asynchronous task due to the user leaving the front-end application page of the cloud service platform, so that the client can still obtain the status information of the target asynchronous task as needed even when the user leaves the front-end application page.

[0047] The system architecture of the embodiments of this application will be described exemplarily below.

[0048] like Figure 1 As shown in the illustration, this application provides a cloud service system, which includes a client and a cloud service platform. The client includes a browser and a service thread running on the client.

[0049] A browser is used to open and display the front-end application page of a cloud service platform.

[0050] Service threads, such as a JavaScript script that runs independently in a browser and can also run independently in a front-end application on a cloud service platform, are used to obtain status information of asynchronous tasks executed on the cloud service platform.

[0051] The front-end application of the cloud service platform is used to instruct the cloud service platform to perform various asynchronous tasks, such as browser / server (B / S) architecture web applications and progressive web applications (PWAs).

[0052] A cloud service platform is used to execute asynchronous tasks issued by front-end applications and return the status information of these tasks to the client's service thread. Examples include application programming interface (API) servers and content delivery networks (CDNs). Specifically, the front-end application of the cloud service platform (or the browser hosting the front-end application) retrieves the status information of the asynchronous tasks from the cloud service platform via HTTP requests.

[0053] The devices on which the client is deployed in the above system can be mobile phones, tablets, handheld computers, personal computers (PCs), cellular phones, personal digital assistants (PDAs), wearable devices (such as smartwatches, smart bracelets, etc.), smart home devices (such as televisions, etc.), in-vehicle systems (such as in-vehicle computers, etc.), smart screens, laptops, desktop computers, or all-in-one computers, etc.

[0054] It should be noted that this application does not limit the form of the cloud service platform. Specifically, the device deploying the cloud service platform in the above system can be a server or a server cluster. The server can be a physical server or a virtualization platform. There can be a single physical server, or two or more physical servers sharing different responsibilities, with each physical server cooperating to achieve its various functions.

[0055] For example, the server can be a blade server, a high-density server, a rack server, or a tower server, etc.

[0056] Optionally, the cloud service system also includes a load balancing module. This load balancing module receives requests from clients (such as browsers) and determines which server, such as the nginx load balancer, to forward these requests for processing.

[0057] The devices in the above system that deploy the load balancing module can be servers or server clusters.

[0058] It should be noted that the system architecture and application scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of system architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0059] For ease of understanding, the task status acquisition method provided in this application is described below with reference to the accompanying drawings. This task status acquisition method is applicable to... Figure 1 The system shown.

[0060] like Figure 2 As shown in the figure, this application embodiment provides a task status acquisition method, which can be executed by a service thread running on a client, and the method includes:

[0061] S201, the service thread obtains the status retrieval instruction corresponding to the target asynchronous task.

[0062] In some embodiments, the target asynchronous task can be any asynchronous task triggered by the user through a front-end application, instructing the cloud service platform to execute it. Specifically, this could be restarting a database instance, uploading a file to cloud storage, submitting an order, or transcoding a video. The number of target asynchronous tasks can be one or more. If a user triggers multiple target asynchronous tasks simultaneously, these tasks can be executed in parallel by the cloud service platform, or they can be executed sequentially by the cloud service platform.

[0063] The status retrieval instruction corresponding to the target asynchronous task is used to instruct the service thread to retrieve the status information of the target asynchronous task on the cloud service platform. In some implementations, the status retrieval instruction includes request information, which is used by the service thread to generate a status retrieval request.

[0064] Optionally, the request information includes the Uniform Resource Identifier (URI) of the target asynchronous task. The URI of the target asynchronous task is used to indicate that the status information of the target asynchronous task is being queried. This URI points to the API endpoint corresponding to the target asynchronous task on the cloud service platform, which can provide the status information of the target asynchronous task.

[0065] Optionally, the request information may also include request parameters that identify the target asynchronous task.

[0066] For example, request parameters include path parameters and / or query parameters. Path parameters are located in the URI path and are used to uniquely identify the target asynchronous task. Query parameters are located in the query string of the URI and are used to qualify query conditions, such as timestamps.

[0067] In some embodiments, the aforementioned request information may be request information returned by the cloud service platform and received by the front-end application.

[0068] In other embodiments, the aforementioned request information may be request information generated by the front-end application. For example, this request information may be information inferred from the representative state transfer (RESTful) API specification, used by the service thread to generate a state retrieval request. RESTful API is a design style based on the HTTP protocol used to build web services in distributed systems. It is a concise, scalable, and easy-to-understand API design pattern widely used in the development of modern web and mobile applications. RESTful API abstracts the functional modules of an application into resources. Each resource has a unique URI, through which it is accessed and manipulated. RESTful API provides a unified interface, including using HTTP verbs (GET, POST, PUT, DELETE, etc.) to operate on resources and using HTTP status codes to convey the results of operations. For example, the resource may be an asynchronous task.

[0069] In this embodiment, the service thread can send a status retrieval request to the cloud service platform to obtain the current status information of the target asynchronous task, based on a status retrieval instruction including request information.

[0070] In some embodiments, the service thread obtaining the status acquisition instruction corresponding to the target asynchronous task includes: the service thread receiving the status acquisition instruction corresponding to the target asynchronous task sent by the front-end application. For example, after sending the target asynchronous task to the cloud service platform, the front-end application can send the status acquisition instruction corresponding to the target asynchronous task to the service thread. In this way, the front-end application actively instructs the service thread to obtain the current status information of the specified asynchronous task according to its needs, and the service thread obtains the current status information of the asynchronous task based on the instruction of the front-end application, which better meets the needs of the front-end application.

[0071] In some embodiments, the front-end application includes a target method. The target method is used to instruct the cloud service platform to execute the target asynchronous task in response to a triggering operation of a target asynchronous task in the front-end application, such as sending an execution instruction for the target asynchronous task to the cloud service platform. The target method is configured with a decorator. The decorator is used to send a status retrieval instruction corresponding to the target asynchronous task to the service thread after the target method is invoked. The triggering operation is the operation that triggers the target asynchronous task (such as clicking a button to start the asynchronous task). In this embodiment, by configuring a decorator in the target method of the front-end application, after the user triggers the target asynchronous task of the front-end application, a status retrieval instruction is automatically sent to the service thread to instruct the service thread to retrieve the status information of the target asynchronous task.

[0072] For example, using TypeScript's decorator feature, a method decorator named `@asyncNotification` can be defined. This `@asyncNotification` decorator is used to send the status retrieval instruction corresponding to the target asynchronous task to the service thread after the target method is called and before the service thread sends a status retrieval request to the cloud service platform based on the status retrieval instruction.

[0073] In some embodiments, the decorator is also used to obtain the request information corresponding to the target asynchronous task returned by the cloud service platform after the target method is invoked, and, if the request information is obtained, to determine the status retrieval instruction containing the request information. In this way, by obtaining the request information returned by the cloud service platform through the decorator, and encapsulating the logic of the status retrieval request (i.e., the status retrieval instruction containing the request information) within the decorator, making it independent of the logic of the target method, the extensibility and maintainability of the code are increased.

[0074] In other embodiments, the decorator is also used to generate request information after the target method is invoked, and, if request information is generated, to determine a status retrieval instruction containing that request information. For example, part of the generated request information might be: URI: / api / poll / {methodPath}. This way, regardless of whether the decorator can obtain the request information returned by the cloud service platform, it can determine the required status retrieval instruction.

[0075] For example, the decorator generates request information for the service thread to generate a status retrieval request, in accordance with the RESTful API specification.

[0076] In other embodiments, if the decorator receives request information returned by the cloud service platform, it determines a status retrieval instruction containing the request information and sends the status retrieval instruction containing the request information to the service thread. If the decorator does not receive request information returned by the cloud service platform, it generates request information, determines a status retrieval instruction containing the request information, and sends the status retrieval instruction containing the request information to the service thread.

[0077] like Figure 3 As shown in the figure, this application embodiment provides a method for sending a status acquisition instruction containing request information to a service thread, applied to a decorator; the method includes:

[0078] In step S501, the decorator determines whether it has received a request from the cloud service platform. If yes, it proceeds to step S502. If no, it proceeds to step S503.

[0079] S502, the decorator determines the status retrieval instruction containing the requested information.

[0080] S503, the decorator generates request information according to the RESTful API specification.

[0081] S504, the decorator determines the status acquisition instruction containing the request information based on the generated request information.

[0082] S505, the decorator sends a status retrieval instruction containing request information to the service thread.

[0083] In some embodiments, the service thread includes a polling queue, which is used to store status retrieval instructions corresponding to asynchronous tasks.

[0084] In some embodiments, when a service thread receives a status retrieval instruction corresponding to a target asynchronous task, it adds the instruction to a polling queue. In this way, by automatically receiving status retrieval instructions from the front-end application and automatically registering these instructions to the polling queue, the service thread can automatically, continuously, and orderly query the status information of each asynchronous task according to the first-in-first-out principle of the instructions in the polling queue.

[0085] Optionally, the polling queue includes one or more status retrieval instructions. When the polling queue includes multiple status retrieval instructions, the service thread can send multiple corresponding status retrieval requests to the cloud service platform based on these instructions, thereby obtaining the status information of multiple target asynchronous tasks. In this way, the service thread can efficiently and orderly retrieve the status information of multiple target asynchronous tasks from the cloud service platform within a certain time period, improving not only the efficiency of retrieving asynchronous task status information but also optimizing the user experience.

[0086] In other embodiments, the front-end application registers the status retrieval instruction corresponding to the target asynchronous task to the polling queue of the service thread.

[0087] Optionally, the decorator is used to register the status retrieval instructions corresponding to the target asynchronous task into the polling queue. That is, the front-end application registers the status retrieval instructions corresponding to the target asynchronous task into the polling queue of the service thread using the decorator. In this way, after the target asynchronous task is triggered, the front-end application automatically registers the status retrieval instructions into the polling queue, enabling the service thread to automatically and continuously query the status information of each target asynchronous task without requiring manual code to handle this process.

[0088] S202, the service thread sends a status retrieval request to the cloud service platform based on the status retrieval instruction.

[0089] In some embodiments, the service thread sends a status retrieval request to the cloud service platform every preset time interval according to the status retrieval instruction, until the preset polling termination condition is met.

[0090] Optionally, the preset time interval can be set based on the execution duration or state changes of the target asynchronous task. For example, if the target asynchronous task has a long execution duration or slow state changes, the preset time interval can be set to a longer duration to reduce unnecessary polling requests and thus reduce additional costs. If the target asynchronous task has a short execution duration or rapid state changes, the preset time interval can be set to a shorter duration to capture the state information of the target asynchronous task more quickly and timely.

[0091] Optionally, the preset time interval can be set according to the user's actual needs. For example, if the user expects immediate feedback, the preset time interval can be set to be shorter. If the user can accept a later status update, the preset time interval can be set to be longer.

[0092] Optionally, the preset time interval can be set to [1 minute, 5 minutes]. For example, the preset time interval can be set to 1 minute, 2.5 minutes, or 5 minutes. This ensures timely acquisition of the status information of asynchronous tasks while reducing unnecessary resource waste.

[0093] Optionally, the preset time interval can be dynamically adjusted. For example, as the target asynchronous task nears completion, the preset time interval can be gradually shortened to improve the timeliness of status information acquisition.

[0094] In this embodiment, the service thread, based on a status acquisition instruction, polls the cloud service platform for the status information of asynchronous tasks at preset time intervals. For example, it sends a status acquisition request to the cloud service platform every 5 minutes to inquire about the status of the target asynchronous task. This timely and automatic acquisition of the target asynchronous task's status information effectively achieves continuous monitoring of the target asynchronous task. Therefore, even when the user leaves the front-end application page, the client can still promptly know the status of the target asynchronous task. Simultaneously, a preset polling termination condition limits the stopping conditions of the status acquisition request, avoiding indefinite polling requests, improving the operational stability of the service thread and the cloud service platform, reducing system resource consumption, and also reducing client power consumption.

[0095] In some embodiments, a timer is established in the service thread to control a preset time interval.

[0096] In some embodiments, the preset polling termination condition includes: the most recently received status information indicates that the target asynchronous task has been completed. For example, if the most recently received status information indicates that the target asynchronous task has been completed, the service thread stops sending status retrieval requests to the cloud service platform. Thus, if the target asynchronous task has been completed, the service thread will no longer send status retrieval requests to the cloud service platform, avoiding invalid query requests to the cloud service platform.

[0097] Optionally, the preset polling termination condition includes: the cumulative duration of receiving status information of the target asynchronous task reaches a preset duration. The cumulative duration of receiving status information of the target asynchronous task refers to the duration from the start of the action of receiving the status information of the target asynchronous task. The preset duration is set according to the user's actual needs. For example, if the preset duration is 10 minutes, the service thread will stop sending status acquisition requests to the cloud service platform when the cumulative duration of receiving status information of the target asynchronous task reaches 10 minutes. This satisfies the user's need to obtain the status information of the target asynchronous task within the preset duration.

[0098] Optionally, the preset polling termination condition includes receiving a preset termination signal sent by the cloud service platform. For example, the preset termination signal can be set according to the user's actual needs. For instance, if the target asynchronous task includes multiple subtasks, and the user only needs to obtain the status information of a portion of the subtasks, the cloud service platform sends a preset termination signal to the service thread after the relevant subtasks have completed execution. Upon receiving this preset termination signal, the service thread stops sending status retrieval requests to the cloud service platform. This allows the user to select the status information of the subtasks to be queried based on their needs, rather than querying the entire target asynchronous task, making the status retrieval process more targeted and avoiding unnecessary resource waste.

[0099] In some embodiments, when an initial polling queue is established in the service thread, the initial polling queue is in an empty queue state, meaning that the initial polling queue does not store status retrieval instructions corresponding to asynchronous tasks, and at this time, the status information of asynchronous tasks is not polled. When the polling queue stores status retrieval instructions corresponding to multiple asynchronous tasks, the service thread sends a status retrieval request to the cloud service platform every preset time interval according to the status retrieval instructions corresponding to the target asynchronous tasks stored in the polling queue, until a preset polling termination condition is met. If the target asynchronous task corresponding to the status retrieval instruction in the polling queue has been completed, the status retrieval instruction is removed from the polling queue. In this embodiment, by establishing a polling queue in the service thread, each status retrieval instruction in the polling queue can independently request status information, improving the efficiency and orderliness of the service thread's polling requests, reducing the request load on the cloud service platform, and improving resource utilization efficiency.

[0100] In some embodiments, the service thread further includes a monitoring mechanism. This monitoring mechanism monitors the status of status retrieval instructions in the polling queue. For example, if the monitoring mechanism detects a new status retrieval instruction in the polling queue, the service thread begins sending a status retrieval request to the cloud service platform. If the monitoring mechanism detects that the target asynchronous task corresponding to the status retrieval instruction in the polling queue has been completed, the service thread removes the status retrieval instruction from the polling queue.

[0101] In some embodiments, when the polling queue stores the status retrieval instructions corresponding to the target asynchronous task, the service thread starts a timer and controls the preset time interval through the timer. When the polling queue is empty, the service thread destroys the timer.

[0102] S203, the service thread receives the status information of the target asynchronous task returned by the cloud service platform.

[0103] In some embodiments, status information can represent the task status of the target asynchronous task. This task status includes states such as completed, pending, processing, interrupted, and processing exception. For example, for an asynchronous task like uploading a file to cloud storage, the status information can be "completed" after the file transfer is completed and verified. For example, for an asynchronous task like a user submitting an order, if the cloud service platform has not yet started processing it, the status information can be "pending." For example, for an asynchronous task like video transcoding, if the uploaded video is being converted from one format to another, the status information can be "processing." This allows users to promptly obtain the current stage of the target asynchronous task and receive accurate status updates without actively querying, reducing uncertainty during the waiting process. Furthermore, in this embodiment, if the status information of the target asynchronous task is "processing interrupted" or "processing exception," the problem can be addressed promptly through the client.

[0104] In other embodiments, status information can represent the progress of the target asynchronous task. For example, for an asynchronous task like uploading a file to cloud storage, the progress could be "30% uploaded," "80% uploaded," or until completion. For an asynchronous task like a user submitting an order, the progress could be "Waiting for bank response," "Payment processing," or "Payment successful." For an asynchronous task like downloading software, the progress could be "45MB / 100MB downloaded." In this way, the client accurately obtains the completion percentage of the asynchronous task.

[0105] In other embodiments, the status information can represent the task status and progress of the target asynchronous task. For example, for an asynchronous task like uploading a file to cloud storage, if the asynchronous task has been completed on the cloud service platform, the status information can be: "Completed / Uploaded 100%". For example, for an asynchronous task like a user submitting an order, if the cloud service platform has not yet started processing it, the status information is "Pending / Waiting for bank response".

[0106] In this embodiment, a service thread running on the client actively sends a status acquisition request to the cloud service platform and receives the status information of the target asynchronous task returned by the cloud service platform. This allows the service thread to communicate between the cloud service platform and the client, replacing the front-end application. This embodiment leverages the existing capabilities of the current front-end application and the cloud service platform without altering the cloud service platform's services or affecting other processes on the client. It ensures that even when the user leaves the front-end application's page on the cloud service platform, the client can still obtain the status information of the target asynchronous task as needed and update its status in real time, improving the user experience. Furthermore, by setting up a service thread, the cost of modifying the client is low, while reducing dependence on the API server.

[0107] In some embodiments, such as Figure 2 As shown, after the service thread receives the status information of the target asynchronous task returned by the cloud service platform, it also includes: S204, the service thread pushes a notification message to the browser, the notification message is used to indicate the task status of the target asynchronous task.

[0108] In some embodiments, the notification message pushed to the browser can indicate the task status of the target asynchronous task. For example, the task status of an asynchronous task like uploading a file to cloud storage is "completed," meaning a message notification is pushed to the browser indicating that the target asynchronous task has been completed. Similarly, the task status of an asynchronous task like a user submitting an order is "pending," meaning a message notification is pushed to the browser indicating that the target asynchronous task is pending processing. Furthermore, the task status of an asynchronous task like video transcoding is "processing," meaning a message notification is pushed to the browser indicating that the target asynchronous task is being processed. This allows users to know the current status of asynchronous tasks promptly without actively querying them, reducing uncertainty during the waiting process. In addition, users can take timely action if the asynchronous task's status is interrupted or encounters an error, such as retrying or contacting customer service, allowing for timely problem identification and resolution.

[0109] In other embodiments, message notifications can also indicate the progress of the target asynchronous task. For example, for an asynchronous task like uploading a file to cloud storage, notifications are pushed to the browser showing "30% uploaded," "80% uploaded," and so on until completion. Similarly, for an asynchronous task like a user submitting an order, notifications are pushed to the browser showing "Waiting for bank response," "Payment processing," or "Payment successful." For an asynchronous task like downloading software, notifications are pushed to the browser showing "45MB / 100MB downloaded." In this way, users can accurately obtain the completion percentage of asynchronous tasks through message notifications, have a rough estimate of the remaining time, and better plan their time.

[0110] In this embodiment, the service thread proactively pushes notification messages to the browser, allowing users to proactively and promptly understand the task status of asynchronous tasks without needing to manually refresh the page or check the status. Simultaneously, pushing notifications to users via the browser ensures they are aware of the task status or progress of asynchronous tasks even while performing other operations. It also reminds users to return to the cloud service platform's front-end application, which helps attract users back, improving user awareness and return rate, and ultimately enhancing the user experience.

[0111] In some embodiments, before pushing a notification message to the browser, the service thread further includes processing the status information of the target asynchronous task returned by the cloud service platform. The service thread determines the notification message based on the processed status information. For example, if the processed status information indicates that the target asynchronous task has been completed, then the notification message indicates that the target asynchronous task has been completed. In this way, the service thread can accurately determine the current status information of the target asynchronous task, making the notification messages subsequently pushed to the user more accurate and convenient.

[0112] In other embodiments, after receiving the status information of the target asynchronous task returned by the cloud service platform, the service thread further includes pushing a notification message to the browser indicating that the target asynchronous task has been completed. This allows users to immediately know the completion status of the asynchronous task without actively refreshing the page or manually checking the task status, and does not affect other processes rendering the current page in the browser, thus optimizing resource utilization and improving the interactivity of the cloud service platform's front-end application.

[0113] In some embodiments, the browser displays a notification message on its currently displayed page even when the front-end application is closed. This ensures that even after the user has closed the front-end application, they can still receive the notification through the browser's currently displayed page. This eliminates reliance on cloud service platform capabilities, enabling users to accurately and promptly receive the status information of the asynchronous task. This prevents users from missing status updates of the asynchronous task, solves the technical problem in related technologies where the status information of asynchronous tasks cannot be received when the front-end application is closed, and improves the user experience.

[0114] like Figure 4 As shown in the embodiment of this application, another method for obtaining task status is provided. This method can be executed by a front-end application on the client. The method includes: S301, the front-end application responds to the triggering operation of the target asynchronous task and sends a status acquisition instruction corresponding to the target asynchronous task to the service thread.

[0115] In this embodiment, when the front-end application responds to a user's triggered operation (such as clicking a button to start an asynchronous task), the front-end application sends a status retrieval instruction to the service thread. Upon receiving the status retrieval instruction, the service thread sends a status retrieval request to the cloud service platform according to the instruction, and receives the status information of the target asynchronous task from the cloud service platform. In this way, through the collaboration between the front-end application and the service thread, the client achieves real-time, automatic, and accurate acquisition of the status information of the asynchronous task, improving user satisfaction and optimizing resource utilization.

[0116] In some embodiments, before the front-end application sends a status retrieval instruction corresponding to the target asynchronous task to the service thread in response to the triggering operation of the target asynchronous task, the method further includes: the client registering the service thread in response to the startup of the front-end application. By pre-registering the service thread when the front-end application starts, additional time latency can be reduced, enabling the service thread to respond to subsequent communication needs more quickly. In this way, the registered service thread communicates between the cloud service platform and the client on behalf of the front-end application. Since the service thread can run independently in the browser, the client can still receive the status information of the target asynchronous task even when the user leaves the front-end application's page.

[0117] like Figure 5 As shown in the embodiment of this application, another method for obtaining task status is provided. This method can be executed by a cloud service platform. The method includes: S401, the cloud service platform responds to the status acquisition request and returns the status information of the target asynchronous task to the service thread.

[0118] In this embodiment, through collaboration between the front-end application, service thread, and cloud service platform, the client achieves real-time, automatic, and accurate acquisition of the status information of asynchronous tasks executed by the cloud service platform. Specifically, the service thread interacts directly with the cloud service platform instead of the front-end application, and the cloud service platform sends the status information of the target asynchronous task to the service thread. This approach, by setting up a service thread, minimizes the cost of modifying the client and reduces dependence on servers (such as API servers), ensuring that the client can still obtain the status information of the target asynchronous task on demand even when the user leaves the front-end application page of the cloud service platform. Furthermore, it improves the performance and scalability of the cloud service system.

[0119] like Figure 6 As shown in the figure, this application embodiment provides a task status acquisition device 200, which is applied to a client and includes: an acquisition module 21, a sending module 22, and a receiving module 23. The acquisition module 21 is used to acquire a status acquisition instruction corresponding to a target asynchronous task. The sending module 22 is used to send a status acquisition request to a cloud service platform according to the status acquisition instruction. The receiving module 23 is used to receive the status information of the target asynchronous task returned by the cloud service platform.

[0120] like Figure 7 As shown, this application embodiment provides an electronic device 500. The electronic device 500 includes a processor 510 and a memory 520 for storing processor-executable instructions. When the processor 510 is configured to execute instructions, the electronic device 500 implements the task state acquisition method described above.

[0121] Figure 7The electronic device 500 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0122] Electronic device 500 is manifested in the form of a general-purpose computing device. The components of electronic device 500 may include, but are not limited to: one or more processors 510, memory 520, communication bus 540 connecting different system components (including memory 520 and processor 510), and communication interface 530.

[0123] The communication bus 540 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. Examples of these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0124] Electronic devices 500 typically include a variety of computer system-readable media. These media can be any available media that can be accessed by the electronic device, including volatile and non-volatile media, removable and non-removable media.

[0125] Memory 520 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) and / or cache memory. The electronic device may further include other removable / non-removable, volatile / non-volatile computer system storage media. Although Figure 7As not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disc drive for reading and writing to a removable non-volatile optical disc (e.g., a compact disc read-only memory (CD-ROM), a digital video disc read-only memory (DVD-ROM), or other optical media) may be provided. In these cases, each drive may be connected to the communication bus 540 via one or more data media interfaces. The memory 520 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of this application.

[0126] A program / utility having a set (at least one) of program modules can be stored in memory 520. Such program modules include—but are not limited to—an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. The program modules typically perform the functions and / or methods described in the embodiments of this application.

[0127] Electronic device 500 can also communicate with one or more external devices (e.g., keyboard, pointing device, display, etc.), and with one or more devices that enable a user to interact with the electronic device, and / or with any device that enables the electronic device to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed through communication interface 530. Furthermore, electronic device 500 can also communicate through a network adapter (… Figure 7 (Not shown) communicates with one or more networks (e.g., Local Area Network (LAN), Wide Area Network (WAN), and / or public networks, such as the Internet). The aforementioned network adapter can communicate with other modules of the electronic device via the communication bus 540. It should be understood that, although... Figure 7 As not shown, other hardware and / or software modules may be used in conjunction with the electronic device 500, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, Redundant Arrays of Independent Drives (RAID) systems, tape drives, and data backup storage systems.

[0128] The processor 510 executes various functional applications and data processing by running programs stored in the memory 520, such as implementing the remote access method provided in the embodiments of this application.

[0129] It is understood that the interface connection relationships between the modules illustrated in the embodiments of this application are merely illustrative and do not constitute a structural limitation on the electronic device 500. In other embodiments of this application, the electronic device 500 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0130] It is understood that the aforementioned electronic devices, etc., include hardware structures and / or software modules corresponding to perform each function in order to achieve the above-mentioned functions. Those skilled in the art should readily recognize that, in conjunction with the exemplary units and algorithm steps described in conjunction with the embodiments disclosed herein, the embodiments of this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this application.

[0131] This application embodiment can divide the above-mentioned electronic device into functional modules according to the method example described above. For example, each function can be divided into its own functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0132] This application also provides a storage medium storing computer program instructions. When the computer program instructions are executed by an electronic device, the electronic device performs the task status acquisition method described above.

[0133] This application also provides a computer program product, which includes a computer program that, when run on a computer, causes the computer to execute the task status acquisition method provided in this application.

[0134] The electronic devices, storage media, or computer program products provided in the embodiments of this application are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0135] Through the above description of the embodiments, those skilled in the art will clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0136] In the embodiments of this application, the functional units can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0137] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as flash memory, portable hard disk, read-only memory, random access memory, magnetic disk, or optical disk.

[0138] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for obtaining task status, characterized in that, The method is applied to a service thread running on a client, the client including a browser, the browser being used to display the front-end application page of the cloud service platform; the method includes: Obtain the status acquisition instruction corresponding to the target asynchronous task, wherein the target asynchronous task is an asynchronous task that the front-end application instructs the cloud service platform to execute; According to the status acquisition instruction, a status acquisition request is sent to the cloud service platform; the status acquisition request is used to instruct the cloud service platform to return the status information of the target asynchronous task; Receive the status information of the target asynchronous task returned by the cloud service platform.

2. The task status acquisition method according to claim 1, characterized in that, Sending a status acquisition request to the cloud service platform according to the status acquisition instruction includes: According to the status acquisition instruction, a status acquisition request is sent to the cloud service platform once every preset time interval until the preset polling termination condition is met.

3. The task status acquisition method according to claim 2, characterized in that, The preset polling termination condition includes: the most recently received status information indicates that the target asynchronous task has been completed.

4. The task status acquisition method according to any one of claims 1-3, characterized in that, After receiving the status information of the target asynchronous task returned by the cloud service platform, the method further includes: A notification message is pushed to the browser, the notification message being used to indicate the task status of the target asynchronous task.

5. The task status acquisition method according to claim 4, characterized in that, The browser is used to display the notification message on the browser's currently displayed page when the front-end application's page is closed.

6. The task status acquisition method according to any one of claims 1-3, characterized in that, The instruction for obtaining the status corresponding to the target asynchronous task includes: Receive the status acquisition instruction corresponding to the target asynchronous task sent by the front-end application.

7. The task status acquisition method according to claim 6, characterized in that, The front-end application includes a target method, which is used to respond to the triggering operation of the target asynchronous task of the front-end application and instruct the cloud service platform to execute the target asynchronous task; the target method is configured with a decorator; the decorator is used to send a status acquisition instruction corresponding to the target asynchronous task to the service thread after the target method is called.

8. The task status acquisition method according to claim 7, characterized in that, The decorator is also used to obtain the request information corresponding to the target asynchronous task returned by the cloud service platform after the target method is called, and to determine the status acquisition instruction containing the request information when the request information is obtained. The request information is used by the service thread to generate the status acquisition request.

9. The task status acquisition method according to claim 7 or 8, characterized in that, The service thread includes a polling queue, which stores status retrieval instructions corresponding to asynchronous tasks; the decorator is used to register the status retrieval instructions corresponding to the target asynchronous task to the polling queue.

10. A method for obtaining task status, characterized in that, The method is applied to a client, which includes a browser for displaying the front-end application pages of the cloud service platform, and the client also includes a service thread; the method includes: In response to the triggering operation of the target asynchronous task, the front-end application sends a status acquisition instruction corresponding to the target asynchronous task to the service thread. The target asynchronous task is an asynchronous task that the front-end application instructs the cloud service platform to execute. The service thread obtains the status acquisition instruction corresponding to the target asynchronous task; The service thread sends a status retrieval request to the cloud service platform according to the status retrieval instruction; the status retrieval request is used to instruct the cloud service platform to return the status information of the target asynchronous task; The service thread receives the status information of the target asynchronous task returned by the cloud service platform.

11. The task status acquisition method according to claim 10, characterized in that, Before the front-end application sends the status retrieval instruction corresponding to the target asynchronous task to the service thread in response to the triggering operation of the target asynchronous task, it further includes: In response to the startup of the front-end application, the service thread is registered.

12. A method for obtaining task status, characterized in that, The method is applied to a cloud service system, which includes a client and a cloud service platform; the client includes a browser and a service thread, the browser being used to display the front-end application pages of the cloud service platform; the method includes: In response to the triggering operation of the target asynchronous task, the front-end application sends a status acquisition instruction corresponding to the target asynchronous task to the service thread. The target asynchronous task is an asynchronous task that the front-end application instructs the cloud service platform to execute. The service thread obtains the status acquisition instruction corresponding to the target asynchronous task; The service thread sends a status retrieval request to the cloud service platform according to the status retrieval instruction; the status retrieval request is used to instruct the cloud service platform to return the status information of the target asynchronous task; In response to the status acquisition request, the cloud service platform returns the status information of the target asynchronous task to the service thread; The service thread receives the status information of the target asynchronous task returned by the cloud service platform.

13. A task status acquisition device, characterized in that, Applied to a client, the client including a browser, the browser being used to display the front-end application page of the cloud service platform; the device includes: The acquisition module is used to acquire the status acquisition instruction corresponding to the target asynchronous task, wherein the target asynchronous task is an asynchronous task that the front-end application instructs the cloud service platform to execute. The sending module is used to send a status acquisition request to the cloud service platform according to the status acquisition instruction; the status acquisition request is used to instruct the cloud service platform to return the status information of the target asynchronous task; The receiving module is used to receive the status information of the target asynchronous task returned by the cloud service platform.

14. An electronic device, characterized in that, include: A processor, and a memory for storing processor-executable instructions; When the processor is configured to execute the instructions, the electronic device implements the task state acquisition method as described in any one of claims 1-12.

15. A storage medium storing computer program instructions thereon; characterized in that, When the computer program instructions are executed by the electronic device, the electronic device implements the task status acquisition method as described in any one of claims 1-12.

Images