A plug-in extension method and device for a network video recorder's graphical user interface.

Abstract

This invention discloses a method and apparatus for plug-in-based extension of the graphical user interface (GUI) of a network video recorder. The method includes: constructing a GUI runtime framework, which defines a plug-in development specification based on the decoupling of view and model interaction; in response to plug-in loading, creating a dedicated intermediary proxy instance for the plug-in and establishing a metadata binding relationship between the GUI runtime framework and the plug-in; receiving the plug-in's interaction requests through the intermediary proxy instance and verifying and routing the interaction requests based on the metadata binding relationship and pre-defined access control rules; if the verification passes, forwarding the interaction request to the GUI runtime framework for processing to achieve functional extension of the plug-in. This invention achieves flexible, dynamic, and standardized extension of the GUI of a network video recorder while ensuring the stability of core business operations and resource security.

Description

Technical Field

[0001] This invention relates to the field of video surveillance technology, and in particular to a method and apparatus for plugging in a graphical user interface for a network video recorder. Background Technology

[0002] With the deep penetration of edge computing and artificial intelligence technologies in the video surveillance field, network video recorders are evolving from basic recording and storage devices into edge intelligent nodes with proactive sensing capabilities. This evolution has spurred a large number of customized graphical user interface (GUI) interaction requirements deeply tied to specific industry business processes, such as multimodal feature retrieval, real-time intelligent early warning, and industry-specific data visualization. However, current mainstream network video recorder devices generally adopt a closed software architecture with fixed functions. Their GUI is deeply coupled with core business logic, resulting in functions being locked after the device leaves the factory. When any GUI interaction function needs to be added or modified, developers must modify the underlying core code and release a complete firmware. This not only leads to a long development cycle and an inability to respond quickly to market demands, but also makes any customized development for the interface highly susceptible to interfering with the stable operation of core business logic such as video stream processing and storage, seriously violating the core requirement of high reliability for network video recorder devices. Furthermore, existing general-purpose plug-in technologies are not designed for the resource-constrained embedded environments and dedicated resources of network video recorders. They lack fine-grained, controlled access mechanisms for core services such as video streams and metadata. Directly introducing these technologies not only fails to guarantee that core service resources will not be preempted by extended functions, but also introduces system stability risks and security vulnerabilities. Therefore, how to achieve flexible, dynamic, and standardized expansion of the graphical user interface of network video recorders while ensuring the stability of core services and resource security is a pressing technical challenge in this field. Summary of the Invention

[0003] The purpose of this invention is to overcome the shortcomings of the prior art and provide a plug-in extension method and apparatus for the graphical user interface of a network video recorder.

[0004] To achieve the above objectives, the present invention adopts the following technical solution: In a first aspect, the present invention provides a plug-in extension method for the graphical user interface of a network video recorder, comprising: A graphical user interface runtime framework is constructed, which defines a plugin development specification based on the decoupling of view and model interaction. In response to plugin loading, a dedicated intermediary proxy instance is created for the plugin, and a metadata binding relationship is established between the graphical user interface runtime framework and the plugin. The intermediary proxy instance receives the plugin's interaction requests and verifies and routes the interaction requests based on metadata binding relationships and pre-defined access control rules. If the verification passes, the interaction request is forwarded to the graphical user interface runtime framework for processing to extend the functionality of the plugin. Specifically, for requests that need to access core resources, the core business function interface of the network video recorder is invoked for execution, and the business response data is returned to the plugin through the intermediary proxy instance.

[0005] Furthermore, the construction of a graphical user interface runtime framework defines a plugin development specification based on the decoupling of view and model interaction, including: Build a unified graphical user interface runtime framework that follows a declarative programming paradigm; Based on the graphical user interface runtime framework, a standardized plugin application programming interface and plugin encapsulation specification are defined; wherein, the application programming interface includes at least a plugin lifecycle management interface and an interaction interface for implementing data synchronization and command invocation with the graphical user interface runtime framework; the encapsulation specification is used to encapsulate the plugin into an independent functional module containing a list of metadata required for operation and capable of being dynamically loaded and integrated by the graphical user interface runtime framework.

[0006] Furthermore, in response to plugin loading, a dedicated intermediary proxy instance is created for the plugin, and a metadata binding relationship is established between the graphical user interface runtime framework and the plugin, including: During the plugin compilation phase, the interaction logic interface information defined by the plugin according to its declarative programming paradigm is extracted to generate static reflection metadata; During the plugin loading phase, the interface and logic association rules defined in the plugin configuration are parsed to generate interaction rule description information; Based on static reflection metadata and interaction rule description information, a metadata binding relationship between the graphical user interface runtime framework and plugins is built within the intermediary proxy instance.

[0007] Furthermore, the interaction requests include data status synchronization requests, command call requests, and network video recorder core resource access requests; the process of receiving the plugin's interaction requests through the intermediary proxy instance, and verifying and routing the interaction requests based on metadata binding relationships and preset access control rules, includes: The intermediary proxy instance determines the route of received requests based on metadata binding relationships and pre-defined routing strategies; For the plugin's own data state synchronization and command interaction requests, based on the metadata binding relationship, they are converted into the standard interaction format of the graphical user interface runtime framework for processing; For requests to access the core resources of the network video recorder, security verification is performed according to the set access control policy, which includes plugin declarations, user authorizations, and system rules.

[0008] Furthermore, for core resource access requests that pass the verification, the intermediary proxy instance forwards them to the core business function interface of the network video recorder for processing via the graphical user interface runtime framework; requests that fail the verification are rejected.

[0009] Furthermore, the business response data is returned to the plugin via the intermediary proxy instance, including: The graphical user interface runtime framework returns business response data to the requesting plugin through an isolated interaction link via an intermediary proxy instance, so that the plugin updates its state or interface based on the feedback data.

[0010] Furthermore, it also includes: The intermediary proxy instance monitors the running status of the plugins it is bound to and records the plugins' key operation logs.

[0011] Secondly, the present invention also provides a plug-in extension device for a network video recorder's graphical user interface, comprising: The building block is used to build a graphical user interface runtime framework, which defines a plugin development specification based on the decoupling of view and model interaction. Create a unit to respond to plugin loading, create a dedicated intermediary proxy instance for the plugin, and establish a metadata binding relationship between the graphical user interface runtime framework and the plugin; The verification and distribution unit is used to receive the interaction requests from the plugin through the intermediary proxy instance, and to verify and route the interaction requests based on the metadata binding relationship and the pre-defined access control rules. The execution unit, if the verification passes, forwards the interactive request to the graphical user interface runtime framework for processing, thereby enabling the expansion of the plugin's functionality. Specifically, for requests that require access to core resources, it calls the core business function interface of the network video recorder to execute and returns the business response data to the plugin via the intermediary proxy instance.

[0012] Thirdly, the present invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement a plug-in extension method for a network video recorder graphical user interface as described above.

[0013] Fourthly, the present invention also provides a computer-readable storage medium storing a computer program, the computer program including program instructions, which, when executed by a processor, cause the processor to perform a plug-in extension method for a network video recorder graphical user interface as described above.

[0014] The beneficial effects of this invention compared to existing technologies are as follows: By constructing a graphical user interface runtime framework that defines decoupling specifications and creating a dedicated intermediary proxy instance for each plugin to establish metadata binding relationships, the interactive requests of plugins are uniformly verified and routed, achieving operational isolation and controlled access to resources between plugins and core business. It can securely and dynamically extend the graphical user interface functions of network video recorders without intrusive modifications to the host's native code. This solves the problems of functional rigidity and agile expansion caused by traditional closed architectures, and fundamentally eliminates the interference of plugin anomalies on the stability of core business. At the same time, the built-in security verification mechanism provides a secure and controllable technical foundation for third-party developers to participate in ecosystem innovation.

[0015] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention, it can be implemented according to the contents of the specification. In order to make the above and other objectives, features and advantages of the present invention more obvious and understandable, preferred embodiments are described in detail below. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A flowchart illustrating a plug-in extension method for a network video recorder's graphical user interface, provided as a specific embodiment of the present invention; Figure 2 A schematic block diagram of a plug-in extension device for a graphical user interface of a network video recorder, provided for a specific embodiment of the present invention; Figure 3 This is a schematic block diagram of a computer device provided for a specific embodiment of the present invention. Detailed Implementation

[0018] The technical solution of the present invention will be clearly and completely described below with reference to specific embodiments. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0020] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0021] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0022] like Figure 1 As shown, this embodiment of the invention provides a plug-in extension method for the graphical user interface of a network video recorder, including the following steps: S10-S40.

[0023] S10. Construct a graphical user interface runtime framework. The graphical user interface runtime framework defines a plugin development specification based on the decoupling of view and model interaction.

[0024] In some embodiments, step S10 specifically includes the following steps: S101-S102.

[0025] S101. Build a unified graphical user interface runtime framework that follows the declarative programming paradigm.

[0026] S102. Define standardized plugin application programming interfaces and plugin encapsulation specifications based on the graphical user interface runtime framework; wherein, the application programming interface includes at least a plugin lifecycle management interface and an interaction interface for implementing data synchronization and command invocation with the graphical user interface runtime framework; the encapsulation specification is used to encapsulate plugins into independent functional modules containing a list of metadata required for operation and capable of being dynamically loaded and integrated by the graphical user interface runtime framework.

[0027] For steps S101-S102, the graphical user interface runtime framework adopts a declarative programming paradigm with built-in data binding and command routing mechanisms. Plugin developers define the interface layout and its association rules with logical units through declarative interface description files. When a property value in a logical unit changes, the framework automatically updates the associated interface elements based on the established binding relationships. Conversely, when a user performs an operation on the interface, the framework converts the operation into a command and routes it to the corresponding processing function in the logical unit based on the binding relationships. Through this decoupled design, plugin developers can extend functionality using a development paradigm consistent with the host application. While focusing on business logic implementation, they can flexibly define the interface presentation through declarative interface descriptions, significantly reducing the technical threshold and complexity of plugin development.

[0028] Furthermore, the graphical user interface runtime framework defines standardized plugin application programming interfaces (APIs) and plugin encapsulation specifications. The APIs include at least a lifecycle management interface, which the framework can call during plugin loading, activation, hibernation, and unloading phases; the interaction interfaces include data synchronization and command invocation interfaces, used to implement data interaction and function calls between plugins and the framework.

[0029] S20. In response to the loading of the plugin, create a dedicated intermediary proxy instance for the plugin and establish a metadata binding relationship between the graphical user interface runtime framework and the plugin.

[0030] In some embodiments, step S20 specifically includes the following steps: S201-S203.

[0031] S201. During the plugin compilation phase, extract the interaction logic interface information defined by the plugin according to its declarative programming paradigm, and generate static reflection metadata.

[0032] This step is performed during the plugin development and compilation phase. Based on the unified graphical user interface runtime framework built in the previous steps and following the declarative programming paradigm, the static reflection technology of the graphical user interface runtime framework is used to scan, parse and extract information from the plugin source code, and finally generate structured static reflection metadata. This metadata is the core basic data for the framework and plugin to achieve automated interaction. It is stored in the plugin package and called by the subsequent plugin loading phase.

[0033] Plugin developers strictly follow the declarative programming paradigm defined by the graphical user interface runtime framework to complete plugin source code development. That is, all interactive logic interfaces of the plugin are written according to the framework's preset annotations, syntax specifications, and interface definition rules. The framework's static reflection mechanism can scan and parse the plugin source code without discrimination based on this unified specification, ensuring the accuracy and completeness of interface information extraction, without requiring developers to write additional information extraction adaptation code.

[0034] The static reflection tool scans the plugin's source code, covering all logical interfaces that interact with the graphical user interface runtime framework and NVR core resources. The extracted information is the core characteristic information of the plugin's interaction, including at least interface signature information and data structure information.

[0035] The static reflection tool performs structured processing on the extracted interaction logic interface information. Following the metadata format standard preset by the graphical user interface runtime framework, it converts the information into machine-readable, structured static reflection metadata, which can be directly read and parsed by the framework. Simultaneously, the generated static reflection metadata is encapsulated in the metadata manifest within the plugin package, facilitating rapid reading by the runtime framework during the plugin loading phase. Furthermore, the metadata file includes version verification information to ensure interface version compatibility between the framework and the plugin.

[0036] This step utilizes static reflection technology to extract interactive logic interface information and generate metadata during the plugin compilation phase. This eliminates the need for manual information processing, achieving automated and standardized extraction of interface information and significantly improving the efficiency of plugin development and integration. Simultaneously, the generated static reflection metadata provides a unified, machine-readable data foundation for interaction between the framework and plugins, ensuring that the framework can accurately identify and call various interactive interfaces of the plugins. Furthermore, the pre-generation and storage of metadata avoids dynamic parsing and discovery of plugin interface information during runtime, reducing runtime resource overhead and adapting to the resource-constrained characteristics of NVR embedded devices.

[0037] S202. During the plugin loading phase, the interface and logic association rules defined in the plugin configuration are parsed to generate interaction rule description information.

[0038] The plugin interface description file is a declarative configuration file written by plugin developers according to the standardized specifications of the graphical user interface runtime framework, and stored within the plugin package. This file defines all the interface and logical relationship rules of the plugin using a structured declarative syntax; these rules serve as the mapping basis between the plugin's interface presentation and the backend interaction logic.

[0039] The configuration parsing module of the graphical user interface runtime framework performs a full parsing of the plugin configuration file. The extracted interface and logic association rules cover all graphical user interface interaction scenarios of the plugin. The core parsing content includes at least the mapping rules between interface components and interaction logic, the triggering rules of events and commands, and the linkage rules of data updates.

[0040] The framework's configuration parsing module performs structured validation and transformation on the extracted interface and logical association rules, eliminating invalid configurations and verifying the syntax validity and logical consistency of the configurations. For valid association rules, it generates structured interaction rule description information according to the rule description format preset by the graphical user interface runtime framework. This description information uses a storage format compatible with static reflection metadata, facilitating subsequent fusion processing with static reflection metadata. The generated interaction rule description information is temporarily stored in the graphical user interface runtime framework's memory cache and bound to the corresponding plugin's identifier. It is only used for the construction of metadata binding relationships and runtime interactions for that plugin. This information is synchronously cleared after the plugin is uninstalled to avoid consuming the NVR device's memory resources.

[0041] This step generates interaction rule description information by parsing the plugin configuration file during the plugin loading phase. This achieves decoupling and standardized parsing of the plugin interface presentation and interaction logic. Developers can flexibly adjust the interface and logic relationship of the plugin by modifying the configuration file without modifying the plugin execution code, thus improving the plugin's customization flexibility. At the same time, the generated interaction rule description information clarifies the linkage between the plugin interface and the backend logic, providing a rule basis for the interface interaction dimension for the subsequent construction of metadata binding relationships, ensuring that the framework can accurately respond to various user operations on the plugin interface. In addition, the standardized parsing of the configuration file and the temporary in-memory storage of the rule information are adapted to the resource characteristics of NVR embedded devices, reducing the overhead of persistent storage.

[0042] S203. Based on static reflection metadata and interaction rule description information, construct the metadata binding relationship between the graphical user interface runtime framework and plugins within the intermediary proxy instance.

[0043] The graphical user interface runtime framework allocates independent runtime resources and context to each plugin to be loaded. Based on the framework's built-in mediator proxy mechanism, a dedicated mediator proxy instance is dynamically created. This instance has independent metadata storage and request management capabilities and is bound one-to-one with the plugin. One plugin corresponds to a unique mediator proxy instance. This instance persists during the plugin's runtime and is synchronously destroyed when the plugin exits or is uninstalled, ensuring on-demand allocation and reclamation of resources. After the mediator proxy instance is created, the framework initializes it, including assigning it a unique instance identifier, initializing the metadata storage area, and loading pre-defined access control rules and routing policies. The instantiated mediator proxy instance has the basic ability to receive and process plugin interaction requests.

[0044] The graphical user interface runtime framework reads the static reflection metadata generated in step S201 and the interaction rule description information generated in step S202 into the metadata storage area of ​​the plugin's dedicated intermediary proxy instance. Then, it performs deep fusion and association mapping on the two types of metadata. The core logic of the fusion is to use the interaction logic interface as the core link, binding the plugin's interface component identifiers, interface events, data linkage rules, and the signatures, data structures, and parameter constraints of the interaction logic interface one by one. This transforms the originally independent static reflection metadata and interaction rule description information into a complete and interconnected metadata system. The fused metadata system is stored in the independent metadata storage area of ​​the intermediary proxy instance, managed and accessed only by this instance. Other plugin intermediary proxy instances and the NVR host application cannot access it, ensuring the isolation and security of the metadata.

[0045] After completing the fusion and association of metadata, the framework constructs a multi-dimensional metadata binding relationship between the graphical user interface runtime framework and plugins within the intermediary proxy instance based on the fused metadata system. This binding relationship is the core data contract for the interaction between the framework and plugins.

[0046] This step creates a dedicated intermediary proxy instance for each plugin and establishes a metadata binding relationship between the framework and the plugin within that instance. Firstly, it achieves metadata isolation between plugins and between plugins and the host application, preventing interference between the metadata of different plugins and ensuring the stability of the NVR system. Secondly, the constructed multi-dimensional metadata binding relationship provides a unified and standardized basis for the verification, routing, and forwarding of subsequent plugin interaction requests, ensuring that the framework can accurately identify and process various plugin interaction requests, achieving seamless interaction between the framework and plugins. Furthermore, the metadata binding relationship is built and solidified within the dedicated intermediary proxy instance, decoupling the plugin's interaction request processing logic from the framework's core logic, reducing the impact of plugin anomalies on the framework's core functionality, and adapting to the 24 / 7 stable operation requirements of NVR core business.

[0047] S30. Receive the interaction requests from the plugin through the intermediary proxy instance, and verify and route the interaction requests based on the metadata binding relationship and the pre-set access control rules.

[0048] Specifically, the interaction requests include data status synchronization requests, command call requests, and network video recorder core resource access requests.

[0049] In some embodiments, step S30 specifically includes the following steps: S301-S303.

[0050] S301. The intermediary proxy instance determines the route of the received request based on the metadata binding relationship and the preset routing strategy.

[0051] During operation, all interactive requests generated by the plugin based on user actions or its own business logic are sent to the intermediary proxy instance it is bound to through a dedicated communication link. The request receiving module of the intermediary proxy instance receives and parses the requests in a unified manner, and then makes a precise route determination on the type, belonging, and processing link of the request based on the metadata binding relationship already built in the instance and the routing strategy pre-set by the graphical user interface runtime framework, providing a basis for subsequent differentiated processing of requests.

[0052] The intermediary proxy instance establishes a one-to-one dedicated communication link with each plugin, receiving only interaction requests initiated by its bound plugins and shielding itself from interference from requests from other plugins and system modules, ensuring the uniqueness and isolation of received requests. Upon receiving an interaction request from a plugin, the request receiving module first performs basic parsing, extracting the core identifier information and basic parameters of the request to complete the standardized initial parsing, providing foundational data for subsequent routing decisions. If the parsing reveals an invalid request format or lack of valid identifier information, the intermediary proxy instance will directly intercept the request and record an exception log, without proceeding to subsequent processing steps.

[0053] The intermediary proxy instance bases its request routing decisions on metadata binding relationships and pre-defined routing strategies. These two factors work together and impose layer-by-layer constraints to ensure the accuracy and compliance of the routing decisions.

[0054] The routing determination module of the intermediary proxy instance performs multi-dimensional routing determination on the parsed requests based on the above dual criteria. The determination process is divided into two core stages, and all determination logic is automatically executed by the module without manual intervention: Legality determination: First, based on the metadata binding relationship, verify whether the request is a legitimate request initiated by the plugin according to the framework development specifications, that is, verify whether the request type, request target, and parameter format are consistent with the legitimate interaction scope of the plugin defined in the metadata binding relationship; if it is determined to be an illegal request, it is directly intercepted and logged; if it is determined to be a legitimate request, proceed to the next stage of determination. Type and Link Determination: The legitimate request is accurately classified into types such as plugin data state synchronization request, plugin command call request, or NVR core resource access request. At the same time, combined with the preset routing policy, the processing link, execution priority and subsequent processing module corresponding to the request type are matched, and a route identifier is added to the request. The request is then forwarded to the corresponding processing module (format conversion module or security verification module) in the intermediary proxy instance to complete the route determination.

[0055] This step achieves unified reception and precise routing of plugin interaction requests through a mediator proxy instance. First, relying on a dedicated communication link and request receiving module, it achieves isolated reception of plugin requests, avoiding interference between requests from different plugins and ensuring the independence of request processing. Second, it performs routing determination based on both metadata binding relationships and pre-defined routing strategies, ensuring that request determination is consistent with the actual development specifications of the plugins and meets the overall resource management and business operation requirements of the NVR system, thus achieving accuracy and compliance in routing determination. In addition, illegal requests are intercepted in advance during the routing determination process, effectively reducing subsequent invalid request processing operations, lowering the resource overhead of the mediator proxy instance and the graphical user interface runtime framework, and adapting to the resource characteristics of NVR embedded devices. At the same time, it matches dedicated processing links and priorities for different types of requests, achieving differentiated scheduling and processing of requests, and improving overall request processing efficiency.

[0056] S302. For the plugin's own data state synchronization and command interaction requests, based on the metadata binding relationship, convert them into the standard interaction format of the graphical user interface runtime framework for processing.

[0057] Requests identified by S301 routing as either plugin data state synchronization requests or plugin command call requests are uniformly processed by the format conversion module of the intermediary proxy instance. These requests are non-core resource interaction requests within the plugin or between the plugin and the graphical user interface runtime framework, and do not involve access to NVR core business resources. Based on the established metadata binding relationship, the format conversion module converts the plugin's custom format requests into a standard interaction format that the GUI runtime framework can directly recognize and process, achieving seamless interaction between the plugin and the framework. Moreover, this conversion process is completely transparent to the plugin developers.

[0058] Specifically, the plugin's own data state synchronization requests and command call requests are non-core resource interaction requests. Their interaction scope is limited to within the plugin itself or between the plugin and the graphical user interface runtime framework. They do not involve access to core resources of the NVR's core business units, such as video encoding / decoding, storage, and stream forwarding. Specifically, they include: Data state synchronization requests: Requests initiated by the plugin to the framework to synchronize its own runtime state data, refresh and synchronize the data of the UI components inside the plugin, and synchronize the general configuration data between the plugin and the framework; Command invocation requests: These are requests initiated by the plugin to the framework to call the framework's general function interfaces, execute commands for the plugin's internal business logic, or invoke commands triggered by plugin UI events. These are the fundamental requests for plugin operation and are processed frequently. Therefore, the framework has implemented a lightweight processing flow for them, requiring only format conversion before handing them over to the framework for processing.

[0059] The sole core basis for format conversion is the metadata binding relationship already built within the intermediary proxy instance. This relationship includes the mapping rules between plugin-customized formats and framework standard formats. Specifically, it includes the field mapping between plugin-customized data structures and framework standardized data structures, the one-to-one correspondence between plugin-customized command identifiers and framework standardized command identifiers, and the conversion rules between plugin-customized request parameters and framework standard request parameters, providing a precise technical basis for format conversion.

[0060] After the plugin request is converted into the standard interaction format of the graphical user interface runtime framework by the format conversion module, the intermediary proxy instance will forward the standardized request directly to the request processing module of the graphical user interface runtime framework according to the preset routing strategy. After receiving the standardized request, the graphical user interface runtime framework does not need to perform additional format parsing. It can directly process the request based on its own data-driven engine and command routing engine, and return the processing result to the intermediary proxy instance through the isolated feedback link. The intermediary proxy instance then forwards it to the plugin, completing the initial processing loop of this type of request.

[0061] This step converts the plugin's own interaction requests into the framework's standard interaction format based on metadata binding relationships. Firstly, it achieves seamless integration between the plugin's custom format and the framework's standard format, allowing plugin developers to customize request formats according to the framework's development specifications without needing to adapt to the framework's underlying format requirements, significantly lowering the development threshold for plugins. Furthermore, the conversion process is completely transparent to developers, improving the development experience. Secondly, the lossless and standardized format conversion ensures the integrity and accuracy of the request information, enabling the graphical user interface runtime framework to directly recognize and process requests without additional format parsing operations, improving request processing efficiency. In addition, this lightweight processing flow for such requests reduces the resource consumption of the intermediary proxy instance and the framework, adapting to the resource-constrained characteristics of NVR embedded devices. Simultaneously, the processing of the plugin's own requests is entirely forwarded by the intermediary proxy instance, without direct interaction with the graphical user interface runtime framework, further strengthening the isolation between the plugin and the framework and preventing abnormal plugin requests from affecting the framework's core functionality.

[0062] S303. For requests to access the core resources of the network video recorder, security verification shall be performed according to the set access control policy, which includes plugin declaration, user authorization and system rules.

[0063] NVR core resource access requests are interactive requests initiated by plugins involving operations on NVR core business resources. The target of these requests is the core capabilities encapsulated by the NVR core business unit, specifically including requests to access real-time video stream data, retrieve recorded storage files, call video codec interfaces, use edge AI intelligent computing power, and access device status metadata. The processing of such requests directly consumes NVR core business resources. Improper handling can easily lead to problems such as core resource contention and interference with core business logic. Therefore, strict security checks are required to achieve fine-grained control over core resources.

[0064] Access control policies are uniformly defined by the graphical user interface runtime framework and pre-configured in the security verification modules of all intermediary proxy instances. This policy is a multi-dimensional, configurable, and dynamic management policy that can be flexibly adjusted according to the NVR's business needs and resource status. Its core includes three dimensions: plugin declaration, user authorization, and system rules. The verification content and basis of each dimension are as follows: Plugin Declaration Dimension: This dimension is the basic verification dimension. The verification basis is the core resource access scope, access permissions, and resource consumption requirements declared by the plugin itself. The security verification module first verifies whether the core resource access request initiated by the plugin is within its own declared access scope. If the request exceeds the declared scope, it is directly judged as verification failure, thus preventing plugins from accessing core resources without authorization from the source. User authorization dimension: This dimension is the permission control dimension. The verification basis is the manual authorization configuration made by the NVR device user for the plugin based on their own business needs. Users can finely configure the access permissions of the core resources of each plugin through the permission management interface of the NVR host application, including allowing or prohibiting access to certain core resources, restricting the frequency or scope of resource access, etc. The security verification module verifies whether the request initiated by the plugin meets the user's manual authorization requirements. If the corresponding authorization from the user is not obtained, the verification is deemed to have failed. System rules dimension: This dimension is the system-wide control dimension. The verification basis is the global system rules formulated by the graphical user interface runtime framework based on the NVR core business operation status. These rules take into account both the 24 / 7 stable operation of the NVR core business and the normal use of plugins. Specifically, they include real-time load limits for core resources, priority rules for plugin resource access, access frequency limits for core resources, and a whitelist of prohibited core resources. The security verification module verifies whether the requests initiated by the plugins comply with the system-wide rules. If the request violates the system rules (such as initiating a request with high resource consumption when the core resource load is too high), it is judged as a verification failure.

[0065] This step performs rigorous, multi-dimensional security checks on NVR core resource access requests based on access control policies that include plugin declarations, user authorizations, and system rules. Firstly, it achieves fine-grained, multi-dimensional control over NVR core resources, restricting plugin access behavior at three levels: plugin self-declaration, user manual authorization, and system-wide control. This prevents plugins from unauthorized or illegal access to core resources at the source, ensuring the security of NVR core business resources. Secondly, a veto-based verification principle ensures the rigor of security checks; any request that does not meet control requirements is blocked, effectively preventing plugins from unauthorizedly accessing core business resources and ensuring the stable 24 / 7 operation of NVR core services. Furthermore, the configurability of the access control policies allows NVR device users to flexibly adjust plugin core resource access permissions according to their business needs, while the framework can dynamically adjust system rules based on the core business operation status, improving the flexibility and adaptability of the technical solution. Finally, the detailed verification logs and exception logs generated during the verification process enable monitoring and traceability of plugin core resource access behavior, facilitating subsequent problem investigation and behavior auditing.

[0066] S40. If the verification passes, the interaction request is forwarded to the graphical user interface runtime framework for processing to extend the functionality of the plugin. Specifically, for requests that need to access core resources, the core business function interface of the network video recorder is called to execute, and the business response data is returned to the plugin through the intermediary proxy instance.

[0067] For core resource access requests that pass verification, the intermediary proxy instance forwards them to the core business function interface of the network video recorder for processing via the graphical user interface runtime framework; requests that fail verification are rejected.

[0068] The business response data is returned to the plugin via the intermediary proxy instance. Specifically, the graphical user interface runtime framework returns the business response data to the requesting plugin through an isolated interaction link via the intermediary proxy instance, so that the plugin updates its state or interface based on the feedback data.

[0069] By employing differentiated processing after verification and hierarchical controlled forwarding, plugin access to NVR core resources is under the dual control of the intermediary proxy instance and the graphical user interface runtime framework. This ensures that only legitimate and authorized requests can access core business resources, eliminating issues such as unauthorized plugin access and resource preemption, and guaranteeing the stable 24 / 7 operation of NVR core services. Whether it's the forwarding of core resource access requests or the feedback of business response data, there is no direct interaction link between the plugin and the NVR core business unit. Relying on the intermediary proxy instance and isolated interaction links, comprehensive isolation is achieved between the plugin and the core business in terms of request links, data links, and runtime resources, preventing any interference from plugin anomalies to the core business logic.

[0070] In some embodiments, the network video recorder graphical user interface plug-in extension method further includes the following step: S50.

[0071] S50: Monitor the running status of the plugins bound to it through the intermediary proxy instance, and record the key operation logs of the plugins.

[0072] In summary: By constructing a graphical user interface runtime framework with defined decoupling specifications and creating a dedicated intermediary proxy instance for each plugin to establish metadata binding relationships, unified verification and routing of plugin interaction requests are achieved. This realizes operational isolation between plugins and core business and controlled access to resources. It enables secure and dynamic expansion of the graphical user interface functionality of the network video recorder without intrusive modifications to the host's native code. This solves the problems of functional rigidity and agile expansion caused by traditional closed architectures, fundamentally eliminates the interference of plugin anomalies on the stability of core business, and provides a secure and controllable technical foundation for third-party developers to participate in ecosystem innovation through the built-in security verification mechanism.

[0073] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0074] This invention also provides a plug-in extension device for the graphical user interface of a network video recorder. This device is used to perform the steps in any of the aforementioned embodiments of the plug-in extension method for the graphical user interface of a network video recorder. Specifically, please refer to... Figure 2 , Figure 2 The diagram shows a schematic block diagram of a plug-in extension device 100 for a network video recorder's graphical user interface provided in an embodiment of this application. The plug-in extension device 100 specifically includes: The construction unit 110 is used to build a graphical user interface runtime framework, which defines a plugin development specification based on the decoupling of view and model interaction. The creation unit 120, in response to plugin loading, creates a dedicated intermediary proxy instance for the plugin and establishes a metadata binding relationship between the graphical user interface runtime framework and the plugin. The verification and distribution unit 130 receives interaction requests from the plugin through the intermediary proxy instance and verifies and routes the interaction requests based on the metadata binding relationship and pre-defined access control rules. The execution unit 140, if the verification passes, forwards the interaction request to the graphical user interface runtime framework for processing to extend the plugin's functionality. Specifically, for requests requiring access to core resources, it calls the core business function interface of the network video recorder and returns the business response data to the plugin via the intermediary proxy instance.

[0075] In some embodiments, the construction unit 110 is specifically used to: construct a unified graphical user interface runtime framework that follows a declarative programming paradigm; define standardized plugin application programming interfaces and plugin encapsulation specifications based on the graphical user interface runtime framework; wherein, the application programming interface includes at least a plugin lifecycle management interface and an interaction interface for implementing data synchronization and command invocation with the graphical user interface runtime framework; the encapsulation specification is used to encapsulate plugins into independent functional modules that contain a list of metadata required for operation and can be dynamically loaded and integrated by the graphical user interface runtime framework.

[0076] In some embodiments, the construction unit 120 is specifically used to: extract the interaction logic interface information defined by the plugin according to its declarative programming paradigm during the plugin compilation stage, and generate static reflection metadata; during the plugin loading stage, parse the interface and logic association rules defined in the plugin configuration, and generate interaction rule description information; and based on the static reflection metadata and interaction rule description information, construct the metadata binding relationship between the graphical user interface runtime framework and the plugin within the intermediary proxy instance.

[0077] In some embodiments, the verification and distribution unit 130 is specifically applied to: the intermediary proxy instance performing route determination on the received request based on the metadata binding relationship and the preset routing policy; for the plugin's own data state synchronization and command interaction request, converting it into the standard interaction format of the graphical user interface runtime framework for processing based on the metadata binding relationship; and for the request to access the core resources of the network video recorder, performing security verification based on the set access control policy, wherein the access control policy includes plugin declaration, user authorization and system rules.

[0078] In some embodiments, the network video recorder graphical user interface plug-in extension device is further configured to: for core resource access requests that pass verification, the intermediary proxy instance forwards them to the network video recorder core business function interface for processing via the graphical user interface runtime framework; requests that fail verification are rejected.

[0079] In some embodiments, execution unit 140 is specifically applied to: the graphical user interface runtime framework returning business response data to the requesting plugin via an isolated interaction link through an intermediary proxy instance, so that the plugin updates its state or interface based on the feedback data.

[0080] In some embodiments, the network video recorder graphical user interface plug-in extension device is also specifically used to: monitor the running status of the plug-ins bound to it through an intermediary agent instance and record the key operation logs of the plug-ins.

[0081] It should be noted that those skilled in the art can clearly understand that the specific implementation process of the above-mentioned network video recorder graphical user interface plug-in extension device 100 and each unit can be referred to the corresponding description in the foregoing method embodiments. For the sake of convenience and brevity, it will not be repeated here.

[0082] The aforementioned network video recorder graphical user interface plug-in extension device can be implemented as a computer program, which can be used in, for example... Figure 3 It runs on the computer device shown.

[0083] Please see Figure 3 , Figure 3 This is a schematic block diagram of a computer device provided in an embodiment of this application. The computer device 700 can be a server, wherein the server can be a standalone server or a server cluster composed of multiple servers.

[0084] like Figure 3 As shown, the computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the plug-in extension method steps of the network video recorder graphical user interface as described above.

[0085] The computer device 700 includes a processor 720, a memory, and a network interface 750 connected via a system bus 710, wherein the memory may include a non-volatile storage medium 730 and internal memory 740.

[0086] The non-volatile storage medium 730 can store an operating system 731 and a computer program 732. When the computer program 732 is executed, it enables the processor 720 to execute a plug-in extension method for the graphical user interface of a network video recorder.

[0087] The processor 720 provides computing and control capabilities to support the operation of the entire computer device 700.

[0088] The internal memory 740 provides an environment for the operation of the computer program 732 in the non-volatile storage medium 730. When the computer program 732 is executed by the processor 720, the processor 720 can execute the plug-in extension method of the graphical user interface of the network video recorder.

[0089] This network interface 750 is used for network communication, such as sending assigned tasks. Those skilled in the art will understand that... Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device 700 to which the present application is applied. The specific computer device 700 may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements. The processor 720 is used to run program code stored in memory to implement the plug-in extension method for the graphical user interface of the network video recorder.

[0090] Those skilled in the art will understand that Figure 3 The embodiments of the computer device shown do not constitute a limitation on the specific configuration of the computer device. In other embodiments, the computer device may include more or fewer components than illustrated, or combine certain components, or have different component arrangements. For example, in some embodiments, the computer device may include only memory and a processor. In such embodiments, the structure and function of the memory and processor are different from those shown. Figure 3 The embodiments shown are consistent and will not be described again here.

[0091] It should be understood that, in the embodiments of this application, the processor 720 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0092] In another embodiment of the present invention, a computer-readable storage medium is provided. This computer-readable storage medium may be a non-volatile computer-readable storage medium. The computer-readable storage medium stores a computer program, wherein when executed by a processor, the computer program implements the plug-in extension method for the graphical user interface of a network video recorder disclosed in this embodiment of the present invention.

[0093] Those skilled in the art will readily understand that, for the sake of convenience and brevity, the specific working processes of the devices, apparatuses, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the foregoing description. Whether these functions are implemented in hardware or software 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 this invention.

[0094] In the embodiments provided by this invention, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Units with the same function may be grouped into one unit. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, or may be electrical, mechanical, or other forms of connection.

[0095] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the embodiments of the present invention, depending on actual needs.

[0096] Furthermore, the functional units in the various embodiments of the present invention 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.

[0097] 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 storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, 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.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks.

[0098] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A plug-in extension method for the graphical user interface of a network video recorder, characterized in that, include: A graphical user interface runtime framework is constructed, which defines a plugin development specification based on the decoupling of view and model interaction. In response to plugin loading, a dedicated intermediary proxy instance is created for the plugin, and a metadata binding relationship is established between the graphical user interface runtime framework and the plugin. The intermediary proxy instance receives the plugin's interaction requests and verifies and routes the interaction requests based on metadata binding relationships and pre-defined access control rules. If the verification passes, the interaction request is forwarded to the graphical user interface runtime framework for processing to extend the functionality of the plugin. Specifically, for requests that need to access core resources, the core business function interface of the network video recorder is invoked for execution, and the business response data is returned to the plugin through the intermediary proxy instance.

2. The plug-in extension method for a network video recorder's graphical user interface according to claim 1, characterized in that, The aforementioned construction establishes a graphical user interface runtime framework, which defines plugin development specifications based on the decoupling of view and model interaction, including: Build a unified graphical user interface runtime framework that follows a declarative programming paradigm; Based on the graphical user interface runtime framework, a standardized plugin application programming interface and plugin encapsulation specification are defined; wherein, the application programming interface includes at least a plugin lifecycle management interface and an interaction interface for implementing data synchronization and command invocation with the graphical user interface runtime framework; the encapsulation specification is used to encapsulate the plugin into an independent functional module containing a list of metadata required for operation and capable of being dynamically loaded and integrated by the graphical user interface runtime framework.

3. The plug-in extension method for the graphical user interface of a network video recorder according to claim 1, characterized in that, In response to plugin loading, a dedicated intermediary proxy instance is created for the plugin, and a metadata binding relationship is established between the graphical user interface runtime framework and the plugin, including: During the plugin compilation phase, the interaction logic interface information defined by the plugin according to its declarative programming paradigm is extracted to generate static reflection metadata; During the plugin loading phase, the interface and logic association rules defined in the plugin configuration are parsed to generate interaction rule description information; Based on static reflection metadata and interaction rule description information, a metadata binding relationship between the graphical user interface runtime framework and plugins is built within the intermediary proxy instance.

4. The plug-in extension method for the graphical user interface of a network video recorder according to claim 1, characterized in that, The interaction requests include data status synchronization requests, command call requests, and network video recorder core resource access requests. The step of receiving plugin interaction requests through an intermediary proxy instance and verifying and routing the interaction requests based on metadata binding relationships and pre-defined access control rules includes: The intermediary proxy instance determines the route of received requests based on metadata binding relationships and pre-defined routing strategies; For the plugin's own data state synchronization and command interaction requests, based on the metadata binding relationship, they are converted into the standard interaction format of the graphical user interface runtime framework for processing; For requests to access the core resources of the network video recorder, security verification is performed according to the set access control policy, which includes plugin declarations, user authorizations, and system rules.

5. A plug-in extension method for a network video recorder's graphical user interface according to claim 4, characterized in that, For core resource access requests that pass the verification, the intermediary proxy instance forwards them to the core business function interface of the network video recorder for processing via the graphical user interface runtime framework. Requests that fail validation are rejected.

6. The plug-in extension method for a network video recorder's graphical user interface according to claim 1, characterized in that, The business response data is returned to the plugin via the intermediary proxy instance, including: The graphical user interface runtime framework returns business response data to the requesting plugin through an isolated interaction link via an intermediary proxy instance, so that the plugin updates its state or interface based on the feedback data.

7. The plug-in extension method for a network video recorder's graphical user interface according to claim 1, characterized in that, Also includes: The intermediary proxy instance monitors the running status of the plugins it is bound to and records the plugins' key operation logs.

8. A plug-in extension device for a network video recorder's graphical user interface, characterized in that, include: The building block is used to build a graphical user interface runtime framework, which defines a plugin development specification based on the decoupling of view and model interaction. Create a unit to respond to plugin loading, create a dedicated intermediary proxy instance for the plugin, and establish a metadata binding relationship between the graphical user interface runtime framework and the plugin; The verification and distribution unit is used to receive the interaction requests from the plugin through the intermediary proxy instance, and to verify and route the interaction requests based on the metadata binding relationship and the pre-defined access control rules. The execution unit, if the verification passes, forwards the interactive request to the graphical user interface runtime framework for processing, thereby enabling the expansion of the plugin's functionality. Specifically, for requests that require access to core resources, it calls the core business function interface of the network video recorder to execute and returns the business response data to the plugin via the intermediary proxy instance.

9. A computer device, characterized in that, The device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements a plug-in extension method for a graphical user interface of a network video recorder as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which includes program instructions. When the program instructions are executed by a processor, the processor performs a plug-in extension method for a network video recorder graphical user interface as described in any one of claims 1 to 7.

Images