An online code development system, loader module, and related products

Abstract

The application provides an online code development system, a loader module and related products. The online code development system comprises a first online IDE for online editing of a first code, the first online IDE having a first underlying editing environment for online editing of the first code; a second online IDE for online editing of a second code, the second online IDE having a second underlying editing environment for online editing of the second code; and a plug-in management module having an association relationship with all plug-ins available in the first underlying editing environment and the second underlying editing environment, for managing the plug-ins in at least one of the following manners: monitoring the first underlying editing environment and the second underlying editing environment, determining an effective plug-in, monitoring a plug-in update action and a plug-in addition action, responding to the plug-in update action to update the effective plug-in based on the association relationship, and responding to the plug-in addition action to add a plug-in based on the association relationship.

Description

TECHNICAL FIELD

[0001] The present application belongs to the field of data processing, and particularly relates to an online code development system, a loader module and related products. BACKGROUND

[0002] An online integrated development environment (IDE) is a tool that allows developers to directly develop software on the Internet. The environment integrates key functions such as code editing, compiling, debugging and running. By accessing the online IDE through a browser, developers can use remote development resources for programming work.

[0003] Currently, most online IDEs are based on underlying technologies such as Visual Studio Code (VSCode) or IntelliJ IDEA, and only support plugins compatible with these underlying technologies. In addition, existing online IDEs usually only provide basic preset configurations, and users can customize them on this basis.

[0004] In specific application scenarios, front-end and back-end developers may choose different IDE technology stacks (for example, front-end developers prefer to use VSCode, while back-end developers prefer to use IntelliJ IDEA), which poses a challenge to the unified support of online IDEs. Even if support can be provided, it is difficult to achieve the adaptation and installation of plugins. Online IDEs are usually deployed based on container technology to achieve elastic scaling of resources. However, this deployment method also means that the life cycle of the online IDE instance is closely related to the life cycle of the container instance. In order to optimize the use of server resources, inactive online IDE instances will be released. Since each instance independently manages its configuration file, the release of the instance will cause the reset of the online IDE configuration. SUMMARY

[0005] Based on the above problems, the embodiments of the present application provide an online code development system, a loader module and related products to solve the problems existing in the prior art.

[0006] An embodiment of the present application provides an online code development system, which comprises a first online IDE, a second online IDE and a plug-in management module, the first online IDE is used for online editing of a first code, the first online IDE has a first underlying editing environment for online editing of the first code, the second online IDE is used for online editing of a second code, the second online IDE has a second underlying editing environment for online editing of the second code, the first underlying editing environment is different from the second underlying editing environment, the plug-in management module is connected with the first online IDE and the second online IDE, the plug-in management module has an association relationship with all plug-ins available in the first underlying editing environment and the second underlying editing environment, and the plug-in management module manages plug-ins in at least one of the following manners: monitoring the first underlying editing environment and the second underlying editing environment, determining an effective plug-in, monitoring a plug-in updating action and a plug-in adding action, updating the effective plug-in based on the association relationship in response to the plug-in updating action, and adding a plug-in based on the association relationship in response to the plug-in adding action.

[0007] An embodiment of the present application further provides a plug-in management module, which is connected with a first online IDE for online editing of a first code and having a first underlying editing environment, and a second online IDE for online editing of a second code and having a second underlying editing environment, so as to have an association relationship with all plug-ins available in the first underlying editing environment and the second underlying editing environment, and manage plug-ins in at least one of the following manners based on the association relationship:

[0008] monitoring the first underlying editing environment of the first online IDE and the second underlying editing environment of the second online IDE to determine an effective plug-in;

[0009] monitoring a plug-in updating action and a plug-in adding action, updating the effective plug-in based on the association relationship in response to the plug-in updating action, and adding a plug-in based on the association relationship in response to the plug-in adding action, the first underlying editing environment being different from the second underlying editing environment.

[0010] An embodiment of the present application further provides a computer storage medium, which has a computer executable program stored thereon, and the computer executable program implements a set of plug-in management logic when being run to interact with a first underlying editing environment and a second underlying editing environment to manage plug-ins in the following manner:

[0011] monitoring the first underlying editing environment and the second underlying editing environment, determining the effective plug-ins, monitoring plug-in update actions and plug-in addition actions, responding to the plug-in update actions to update the effective plug-ins based on the association relationship, and responding to the plug-in addition actions to add plug-ins based on the association relationship;

[0012] The first online IDE, the second online IDE, and the plug-in management module, the first online IDE is used for online editing of the first code, the first online IDE has the first underlying editing environment for online editing of the first code, the second online IDE has the second underlying editing environment for online editing of the second code, and the first underlying editing environment is different from the second underlying editing environment.

[0013] The present application provides an online code development system, a loader module and related products, which have the following technical advantages:

[0014] (1) By setting the first online IDE (with the first underlying editing environment) and the second online IDE (with the second underlying editing environment), different developers' needs for different underlying editing environments can be met, such as different IDE technology stacks commonly used by front-end and back-end developers. Moreover, the plug-in management module has an association relationship with all plug-ins available in the two different underlying editing environments, can monitor different underlying editing environments, determine the effective plug-ins, and respond to plug-in update actions and addition actions. This makes it possible to effectively manage plug-ins when facing different underlying editing environments, and solves the problems of difficult unified support and plug-in adaptation and installation difficulties caused by different IDE technology stacks.

[0015] (2) In the present application, the plug-in management module has a specific association relationship with all plug-ins in different underlying editing environments, and it manages plug-ins from the overall system level, rather than relying on a single online IDE instance itself to manage plug-in related configurations. Even if a certain online IDE instance is released due to inactivity or other reasons, the plug-in management module can still accurately perform plug-in update, addition, and other operations based on its association relationship with the plug-ins when other related online IDE instances (such as the first online IDE or the second online IDE) are needed, maintaining the continuity of plug-in related configurations and avoiding configuration reset problems caused by the release of a single online IDE instance.

[0016] To this end, by supporting the first online IDE and the second online IDE of different underlying editing environments, and the plug-in management module cooperating therewith, the needs of different development roles such as front-end and back-end for different IDE technology stacks can be met, so that various developers can select a suitable underlying editing environment for code development according to their own habits and project requirements in the unified online code development system, and can conveniently manage plug-ins, greatly improving the flexibility of development and the compatibility for different development scenarios. In addition, with the help of the plug-in management module, the plug-ins are uniformly managed from the system level, avoiding the waste of resources (such as repeated storage of similar plug-in configurations) that may occur when each online IDE instance manages plug-in configurations separately, and realizing more efficient resource utilization. On the other hand, the problem of configuration resetting caused by the release of the online IDE instance is solved, so that the system configuration is more stable, and the additional workload caused by configuration loss or resetting in the development process is reduced, further optimizing the configuration management of the entire online code development system.

[0017] Furthermore, the plug-in management module can monitor plug-in update actions and addition actions, and respond in a timely manner based on the association relationship thereof with all plug-ins, whether for plug-ins under the first underlying editing environment or the second underlying editing environment. This enables the maintenance and update of plug-ins to be orderly carried out under a unified management mechanism, and developers do not need to worry about the problem of plug-in update not being timely or compatibility problems caused by differences between different underlying editing environments, improving the convenience and reliability of plug-in maintenance and update. BRIEF DESCRIPTION OF DRAWINGS

[0018] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description only some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor.

[0019] Figure 1 The structure schematic diagram of an online code development system according to an embodiment of the present application.

[0020] Figure 2 The structure schematic diagram of a loader module according to an embodiment of the present application.

[0021] Figure 3 The structure schematic diagram of a loader module according to an embodiment of the present application. DETAILED DESCRIPTION

[0022] Implementing any of the technical solutions of the embodiments of the present application does not necessarily need to achieve all the advantages above.

[0023] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. 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.

[0024] Figure 1 This is a schematic diagram of the structure of an online code development system according to an embodiment of this application. Figure 1 As shown, it includes a first online IDE, a second online IDE, and a plugin management module. The first online IDE is used for online editing of first code and has a first underlying editing environment for online editing of the first code. The second online IDE is used for online editing of second code and has a second underlying editing environment for online editing of the second code. The first underlying editing environment is different from the second underlying editing environment. The plugin management module is connected to the first online IDE and the second online IDE. The plugin management module has an association relationship with all plugins available in the first underlying editing environment and the second underlying editing environment to manage plugins in at least one of the following ways: monitoring the first underlying editing environment and the second underlying editing environment to determine the plugins that have taken effect; monitoring plugin update actions and plugin addition actions; responding to the plugin update actions to update the plugins that have taken effect based on the association relationship; and responding to the plugin addition actions to add plugins based on the association relationship.

[0025] To this end, the online code development system of the present application brings many significant technical benefits by setting the first online IDE and the second online IDE with different underlying editing environments, and the plug-in management module closely associated with them. On the one hand, it can well adapt to the needs of different developers such as front-end and back-end developers for different IDE technology stacks. Developers can choose the appropriate environment for code development according to their own habits and project requirements, and the plug-in management module can effectively manage plug-ins, solve the problem of unified support difficulty and plug-in adaptation and installation difficulty caused by different technology stacks, and greatly improve the development flexibility and compatibility for different scenarios. On the other hand, the plug-in management module manages plug-ins from the system level, avoiding the waste of resources caused by the separate management of plug-in configurations by each online IDE instance, achieving efficient resource utilization, and at the same time solving the problem of configuration reset caused by the release of online IDE instances, making the system configuration more stable, reducing the additional workload caused by configuration-related problems during development, and optimizing configuration management. In addition, the plug-in management module can timely monitor and respond to the update and addition actions of plug-ins under different underlying editing environments, so that plug-in maintenance and update can be orderly carried out under a unified mechanism, improving the convenience and reliability of plug-in maintenance and update.

[0026] Optionally, the plug-in management module is further configured to read attribute information of the all plug-ins for maintenance of the all plug-ins, the attribute information comprising: basic information of the plug-in, version of the plug-in, applicable environment of the plug-in, and environment applicable version of the plug-in; if the attribute information reading fails, an independent verification instance is created to load the plug-in corresponding to the attribute information reading failure on the independent verification instance to run, and attribute information of the corresponding plug-in is obtained according to a running result.

[0027] To this end, the plug-in management module reads plug-in attribute information and handles attribute information reading failure related functions, which have the following technical benefits:

[0028] I. Comprehensive and accurate plug-in maintenance

[0029] By reading various attribute information of the plug-in, including basic information, version, applicable environment, and environment applicable version, etc., the plug-in management module can comprehensively and deeply understand the specific situation of each plug-in. This makes the maintenance work of the plug-in more accurate and targeted, such as knowing whether to update in time according to the version information of the plug-in, and ensuring that the plug-in runs correctly in the appropriate underlying editing environment according to the applicable environment and environment applicable version information, thereby effectively avoiding faults caused by mismatch between the plug-in and the environment, and ensuring the stable operation of the entire online code development system.

[0030] II. Fault troubleshooting and adaptation optimization

[0031] When the attribute information reading fails, a separate verification instance is created and the corresponding plug-in is run thereon to obtain the attribute information, which provides an effective way to solve possible plug-in exception conditions. On the one hand, this helps to quickly locate whether the plug-in itself has a problem that causes the attribute information to be unable to be normally read, or other reasons such as compatibility conflicts with the current system environment. On the other hand, after accurate attribute information is obtained by running the plug-in on the separate verification instance, the plug-in can be further adjusted or optimized to better adapt to different underlying editing environments of the online code development system, thereby improving the adaptability and reliability of the plug-in in the entire system.

[0032] III. Improve the overall stability of the system

[0033] With detailed control of plug-in attribute information and effective handling means for attribute information reading failure, the stability of the entire online code development system is significantly improved. Because the plug-in is an important part of the system, whether it can normally run and whether it is adapted to the system environment are directly related to the running state of the system. Through the above functions of the plug-in management module, potential problems related to the plug-in can be discovered and solved in a timely manner, reducing the risk of system crashes, abnormal functions and other risks caused by plug-in failures or mismatches, and ensuring that the system can continuously and stably provide services for developers.

[0034] IV. Facilitate developer management

[0035] For developers, the plug-in management module can clearly present various attribute information of the plug-in, so that they can more intuitively understand the function, scope of application, version situation and other information of each plug-in. When updating, replacing or troubleshooting the plug-in, developers can make reasonable decisions based on these accurate attribute information, greatly improving the convenience and effectiveness of the developer's plug-in management, and thereby improving the efficiency of the entire development work.

[0036] In specific implementation, the technical implementation of the above plug-in management module functions is as follows:

[0037] For plug-in attribute information reading, the plug-in management module establishes a special information acquisition interface with each plug-in. These interfaces are responsible for extracting relevant attribute information from the internal data structure or configuration file of the plug-in. For example, for the basic information of the plug-in, the plug-in name, author, description and other content can be obtained by reading a specific field in the plug-in metadata file; for version information, the accurate version number can be obtained from the plug-in version identifier file or a specific version record area.

[0038] In addition, the interface interacts with the relevant part of the plugin code for environment compatibility detection to obtain the underlying editing environment type (such as a specific version of VSCode or IntelliJ IDEA, etc.) and the corresponding environment version range information that it can adapt to, according to the applicable environment and environment applicable version attributes of the plug-in.

[0039] For data parsing and sorting, once the original plugin attribute information data is obtained through the interface, data parsing operations will be performed inside the plugin management module. For different formats of data (such as text format, binary format, etc.), corresponding parsing algorithms will be used to convert them into structured data forms that can be processed and understood. The parsed attribute information will be sorted according to the established classification method, such as storing basic information, version information, applicable environment information, and environment applicable version information in different memory areas or data structures, for subsequent query, analysis, and maintenance operations.

[0040] For handling attribute information reading failure, the plugin management module will set up corresponding detection mechanisms to determine whether reading has failed during the process of trying to read the plugin attribute information. This may include checking whether the obtained data is complete, whether it meets the expected format requirements, whether there are data missing or errors, etc. For example, if the read plugin version information is not a valid version number format (such as missing numbers, containing illegal characters, etc.), or the applicable environment information is empty (indicating that the plugin cannot adapt to the environment), it is determined that the attribute information reading has failed.

[0041] For independent verification instance creation, when attribute information reading failure is detected, the plugin management module will call system resources to create an independent verification instance. This independent verification instance is a relatively independent isolated space from the normal running environment, which can be implemented based on virtual machine technology, container technology, etc. The purpose is to avoid interference of attribute information reading failure plugins to the normal system running. When creating an independent verification instance, it will allocate memory, CPU, etc. to the instance according to the system resource status and configuration requirements, to ensure that it has enough running ability to load and run the plugin.

[0042] For plugin loading and running, the plugin corresponding to attribute information reading failure is loaded into the created independent verification instance. This involves interacting with the runtime environment of the independent verification instance, and accurately deploying the code and related resources of the plugin into the instance according to the loading specifications and requirements of the plugin.

[0043] Once the plugin is loaded, the plugin is started in the independent verification instance. During the running process, the independent verification instance will monitor the running state of the plugin, record the start time of the plugin, the memory occupation during the running process, whether there are abnormal errors, etc.

[0044] For attribute information acquisition from running results, attribute information of the plug-in is acquired according to the result of running of the plug-in in the independent verification instance. For example, if the plug-in successfully connects to a certain underlying editing environment during running and shows adapted environment prompt information, then the applicable environment and environment applicable version information of the plug-in can be determined; if the plug-in shows its version identification or related version prompt during running, then the accurate version information of the plug-in can be acquired. For basic information of the plug-in, it can be comprehensively analyzed and extracted from the user interface, log record and the like exhibited by the plug-in during running in the independent verification instance, such as acquiring the plug-in name from the plug-in start interface and acquiring the plug-in author and the like from the log. The acquired attribute information is verified and arranged again to ensure its accuracy and integrity, and then is updated to the attribute information storage area of the plug-in management module, so as to facilitate normal maintenance operation of the plug-in subsequently.

[0045] Optionally, the plug-in management module is further configured to, after the first online IDE or the second online IDE is restarted, according to the monitored result, re-load the plug-in which has taken effect in the first online IDE or the second online IDE.

[0046] When the plug-in management module has the function of re-loading the plug-in which has taken effect after the first online IDE or the second online IDE is restarted according to the monitored result, there are the following technical benefits:

[0047] I. Maintaining consistency of development environment

[0048] 1. During the restarting process of the online IDE, if there is no such mechanism of re-loading the plug-in which has taken effect, the state of the plug-in after the restart cannot be automatically restored, and the developer can need to manually re-configure and enable each plug-in, which is not only cumbersome but also easy to miss or make configuration errors. Through the automatic re-loading function of the plug-in management module, the effective state of the plug-in before and after the restart can be continued, so that when the developer enters the development environment again, the plug-ins relied on can all be in the state of normal work before, thereby maintaining the consistency of the development environment.

[0049] 2. Different development stages can need to frequently restart the online IDE, for example, in the scenarios of debugging code, switching projects and the like. If the state of the plug-in changes every time the online IDE is restarted, the development environment will be different after each restart, which is extremely unfavorable for the developer who needs to accurately reproduce problems and continuously develop. This function effectively avoids the environment difference caused by the restart, and ensures that the development work can be carried out in a relatively stable and consistent environment.

[0050] II. Improving development efficiency

[0051] 1. The plugin management module automatically reloads the active plugins based on the monitoring results, saving the developers time in configuring the plugins and allowing them to focus more on code development.

[0052] 2. If the plugins are not reloaded in time, some functions may not work properly during development, such as code formatting plugins not being loaded affecting the presentation of code specifications, and debugging plugins not being loaded hindering the smooth progress of debugging work. By reloading the active plugins in time, these problems caused by missing plugins can be effectively avoided, ensuring that development work can be carried out efficiently and smoothly.

[0053] Three, enhance system stability

[0054] 1. During the process of reloading active plugins after restart, the plugin management module operates based on monitoring results. This means that it ensures that the reloaded plugins remain compatible with the online IDE after restart, avoiding system instability or abnormal plugin operation caused by compatibility issues, further enhancing the stability of the entire online code development system.

[0055] 2. This function makes the loading of plugins have a standardized process to follow in the special case of online IDE restart, that is, accurately reloading active plugins according to monitoring results. This standardized operation helps to reduce the risk of system failure caused by improper plugin loading, improving the overall reliability of the system.

[0056] Therefore, in a specific application scenario, implementing the plugin management module to reload active plugins based on monitoring results after the first online IDE or the second online IDE restart can include the following technical processing process:

[0057] For the monitoring and data recording phase, during the normal operation of the first online IDE and the second online IDE, the plugin management module continuously monitors the plugins running on these two IDEs. The monitoring content includes the running state of the plugins (such as whether they are running, whether they have errors, etc.), the interaction between the plugins and the IDE (such as whether they normally receive and process the instructions issued by the IDE), and the resource occupation of the plugins (such as memory and CPU occupation, etc.). By embedding specific monitoring code segments in the plugin code or using the plugin monitoring interface provided by the IDE, the plugin management module can obtain real-time information related to the plugins and store it in the local monitoring data storage area (which can be in the form of a database, memory cache, etc.) for subsequent analysis and processing.

[0058] Based on the continuous monitoring of the plugins, the plugin management module can explicitly identify which plugins are active on the first online IDE and the second online IDE. The criteria for determining whether a plugin is active can include whether the plugin successfully starts, whether it completes the necessary initialization process and can normally respond to relevant operations of the IDE, etc.

[0059] For active plugins, the plugin management module will record detailed information about them, such as the unique identifier of the plugin (which can be a unique code generated by combining the plugin name, version number, author, etc.), the installation path of the plugin in the IDE, information about other components or libraries that the plugin depends on, etc. These records are also stored in the monitoring data storage area, providing accurate data basis for subsequent reloading operations.

[0060] For the IDE restart detection and response stage, the plugin management module will interact with the underlying systems of the first online IDE and the second online IDE to monitor the running status of these two IDEs in real time. When detecting that the first online IDE or the second online IDE has a restart event (such as receiving a restart notification signal sent by the IDE, or discovering that the restart process is in progress by periodically checking the process status of the IDE), the plugin management module will immediately start the plugin reloading process for this restart.

[0061] After learning about the IDE restart, the plugin management module will first read all the information about the active plugins on the restarted IDE from the monitoring data storage area. This includes obtaining the unique identifier, installation path, and dependent component information of the active plugins, so as to accurately find the plugins that need to be reloaded and fully prepare for subsequent reloading operations.

[0062] For the plugin reloading stage, according to the installation path and unique identifier of the active plugins read, the plugin management module will accurately find the corresponding plugin resources in the local storage system or remote server (if the plugin resources are stored remotely). This may involve operations such as traversing file system directories, querying database records, etc., to ensure that complete plugin files and related resources (such as plugin configuration files, dependent library files, etc.) can be obtained.

[0063] Before reloading the plugin, the plugin management module will again check the compatibility of the plugin with the restarted online IDE. This can include comparing the minimum required IDE version required by the plugin with the actual version of the restarted IDE, checking whether the components or libraries that the plugin depends on are still available in the restarted IDE environment, etc. If compatibility problems are found, the plugin management module may take appropriate remedial measures, such as trying to update the plugin version, installing missing components or libraries, etc., to ensure that the plugin can run smoothly in the restarted IDE environment.

[0064] Once it is determined that the plug-in is compatible with the restarted IDE and the complete plug-in resources have been found, the plug-in management module will re-load the plug-in into the first online IDE or the second online IDE according to the plug-in loading specification of the IDE. This may involve calling the plug-in loading function of the IDE, passing relevant parameters (such as the installation path of the plug-in, the configuration file path, etc.), and the like, to ensure that the plug-in can be started and run correctly.

[0065] During the re-loading process, the plug-in management module also monitors the re-loading status of the plug-in in real time, such as whether it is successfully started, whether an error occurs, and the like, and feeds back this information to the developer in a timely manner (which can be through a message prompt box, log recording, or the like of the IDE), so that the developer can understand the progress of the re-loading of the plug-in in a timely manner.

[0066] Optionally, the plug-in management module reads attribute information of all the plug-ins through the plug-in reader, and when the reading of the attribute information fails, creates an independent verification instance to run the plug-in corresponding to the reading failure and acquires the attribute information of the corresponding plug-in according to the running result.

[0067] To this end, the plug-in management module, through the way of obtaining plug-in attribute information through the plug-in reader and handling the attribute information reading failure, brings the following technical benefits to the online code development system:

[0068] I. Comprehensive and accurate plug-in description

[0069] 1. The attribute information of all the plug-ins is read through the plug-in reader, which can obtain basic information, version, applicable environment, environment applicable version, and the like of the plug-in. This enables the plug-in management module to comprehensively and deeply understand the specific characteristics and requirements of each plug-in, so as to make more accurate decisions in plug-in management, maintenance, and adaptation with the online IDE, and the like.

[0070] 2. Understanding the applicable environment and environment applicable version, and the like of the plug-in helps the plug-in management module to accurately schedule the plug-in to run in the appropriate online IDE (such as the first online IDE or the second online IDE), to ensure that the plug-in can exert the best performance in the underlying editing environment that matches it, and to avoid problems such as abnormal running or limited functions of the plug-in due to environment mismatch.

[0071] II. Effective response to attribute reading failure

[0072] 1. When attribute information reading fails, a separate verification instance is created and the corresponding plug-in is run to obtain the attribute information, providing an effective way to troubleshoot possible faults in the plug-in itself. By running the plug-in in a separate verification instance, the actual performance of the plug-in can be observed, and it can be determined whether the plug-in itself has code problems, the configuration file is damaged, or there is a compatibility conflict with the system environment, etc., causing the attribute information to be unable to be normally read, and then targeted repair measures can be taken.

[0073] 2. Even if attribute information reading fails, complete attribute information can still be obtained in this way, ensuring that the plug-in management module has comprehensive control over the plug-in. This is crucial for subsequent accurate plug-in maintenance, updates, and ensuring the stable operation of the plug-in in the entire online code development system.

[0074] Three, improve the overall stability of the system

[0075] 1. Accurate control of plug-in attribute information and proper handling of attribute information reading failures can help reduce the risk of system instability caused by plug-in problems. For example, if the plug-in version is incompatible with the online IDE but is not discovered in time, it may cause system crashes or unpredictable errors. The above mechanism can effectively prevent such situations from occurring, ensuring the stable operation of the system.

[0076] 2. This standardized way of obtaining plug-in attribute information, including handling attribute information reading failures, optimizes the workflow of the plug-in management module. It enables the plug-in management module to operate smoothly in the face of various plug-in situations, thereby improving the efficiency and reliability of plug-in management in the entire online code development system, and thus enhancing the overall stability of the system.

[0077] Four, facilitate developer management

[0078] 1. For developers, the clear and complete plug-in attribute information obtained by the plug-in management module provides a clear basis for decision-making when selecting, using, and maintaining plug-ins. They can decide whether to use a certain plug-in in a specific project based on the plug-in's applicable environment, version, etc., and when to update or replace the plug-in, etc.

[0079] 2. Developers do not need to spend a lot of effort to troubleshoot attribute information reading failures and obtain related attribute information, as the plug-in management module has already done these tasks through its own mechanism. This greatly simplifies the plug-in management work of developers, allowing them to focus more on core business such as code development, improving development efficiency.

[0080] In a specific application scenario, for example, the technical implementation process of the plug-in management module obtaining plug-in attribute information through the plug-in reader and handling attribute information reading failure is as follows:

[0081] For obtaining plug-in attribute information through the plug-in reader, a special plug-in reader component is built inside the plug-in management module. In the initialization phase, the plug-in reader will interface with the system's plug-in management framework to obtain basic storage locations, access permissions, and other related information about all available plug-ins, so that subsequent accurate finding and reading of attribute information of each plug-in can be achieved.

[0082] At the same time, the plug-in reader will load corresponding parsing libraries or algorithm modules according to the attribute information storage formats (such as JSON, XML, custom binary format, etc.) that different plug-ins may adopt, so that it has the ability to handle multiple formats of information.

[0083] For each plug-in that needs to read attribute information, the plug-in reader will try to establish a direct connection channel with the plug-in. This may involve using appropriate communication protocols (such as HTTP, RPC, etc.) or interface calling mechanisms to achieve interaction with the plug-in according to the type of the plug-in (such as a plug-in developed based on a certain programming language or development framework) and the installation method of the plug-in in the system (such as local installation, remote loading, etc.).

[0084] Through these connection channels, the plug-in reader can send attribute information reading requests to the plug-in and wait for the plug-in's response, thereby starting the process of obtaining attribute information.

[0085] After establishing a connection with the plug-in, the plug-in reader will read each item of attribute information of the plug-in according to the pre-defined attribute information acquisition process.

[0086] For the basic information of the plug-in, it may be read from the metadata file (such as the manifest file) of the plug-in, and the relevant content can be obtained by parsing the specific fields (such as plug-in name, author, description, etc.) in the file.

[0087] The version information of the plug-in is usually obtained from the version identification area (such as the version number file or the specific constant in the plug-in code) specially set by the plug-in, and the plug-in reader will identify and extract the accurate version number.

[0088] For the applicable environment and environment applicable version of the plug-in, the plug-in reader will interact with the code part responsible for environment compatibility detection inside the plug-in to obtain the underlying editing environment type (such as a specific version of VSCode or IntelliJ IDEA, etc.) that the plug-in can adapt to and the corresponding environment version range information.

[0089] During the reading process, the plug-in reader temporarily stores the acquired attribute information (e.g., in a local cache or a memory data structure) for subsequent collation and verification.

[0090] Once the reading of the plug-in attribute information is completed, the plug-in reader collates the acquired information. Different types of attribute information are classified according to a predetermined classification method (e.g., basic information class, version information class, applicable environment class, and environment applicable version class) to facilitate subsequent query, analysis, and management.

[0091] At the same time, the plug-in reader verifies the collated attribute information. The verification content includes the integrity of the information (whether all expected attribute information has been acquired) and the correctness of the format (e.g., whether the version number conforms to the standard format and whether the applicable environment description is clear and accurate). If problems are found, appropriate remedial measures (e.g., re-reading, error prompt, etc.) will be taken in time to ensure that the final acquired attribute information is accurate and reliable.

[0092] For handling attribute information reading failure cases, the plug-in reader sets up a complete failure detection mechanism to determine whether an attribute information reading failure occurs during the reading of the plug-in attribute information.

[0093] The detection basis mainly includes whether the complete response of the plug-in is not received within the specified time (i.e., after sending the reading request, all expected attribute information is not acquired within a certain time), whether the acquired information has obvious format errors (e.g., unrecognized version number format, chaotic applicable environment description, etc.), and whether there is information missing (e.g., some key attribute information is not acquired).

[0094] When any of the above conditions occurs, it is determined that the attribute information reading fails.

[0095] Once the attribute information reading failure is detected, the plug-in management module immediately starts the creation process of an independent verification instance.

[0096] The creation of an independent verification instance can be based on various technologies, such as virtual machine technology and container technology. Taking the container technology as an example, the plug-in management module calls the relevant API of the container management system (e.g., Docker), specifies a suitable container image (which can be a pre-built general container image for verifying plug-ins) according to the system's resource status and configuration requirements, and allocates necessary resources (e.g., memory, CPU, etc.) to it, thereby creating an independent verification instance that is relatively isolated from the main system environment.

[0097] In the creation process, the running parameters of the independent verification instance (such as network settings, file system access permissions, etc.) are explicitly set to ensure that it can normally run the plug-in and obtain relevant attribute information.

[0098] The plug-in corresponding to the attribute information reading failure is loaded into the created independent verification instance. This involves interacting with the runtime environment of the independent verification instance, and according to the loading specifications and requirements of the plug-in, the code and related resources of the plug-in are accurately deployed into the instance. For example, if the plug-in is developed based on a certain programming language, the executable file, dependent library file, etc. of the plug-in need to be loaded into the container in the corresponding position according to the loading mechanism of the language in the container environment. Once the plug-in is loaded, the plug-in is started in the independent verification instance. During the running process, the independent verification instance monitors the running state of the plug-in, records the start time of the plug-in, the memory occupation during the running process, whether there are abnormal errors, etc.

[0099] According to the running result of the plug-in in the independent verification instance, the attribute information of the plug-in is obtained. For the basic information of the plug-in, it may be necessary to comprehensively analyze and extract from the user interface, log recording, etc. exhibited by the plug-in when running in the independent verification instance, such as obtaining the plug-in name from the plug-in start interface, and obtaining the plug-in author information from the log. For the version information of the plug-in, if the plug-in displays its version identifier or related version prompt during the running process, the accurate version number can be obtained. As for the applicable environment and environment applicable version of the plug-in, if the plug-in successfully connects to a certain underlying editing environment during the running process and displays an adaptive environment prompt information, the applicable environment and environment applicable version information can be determined. The obtained attribute result is verified and arranged again to ensure its accuracy and integrity, and then updated to the attribute information storage area of the plug-in management module, so as to facilitate the normal maintenance operation of the plug-in.

[0100] Optionally, the plug-in management module monitors the online IDE instances of the first online IDE and the second online IDE running in the first underlying editing environment and the second underlying editing environment respectively through the first probe created, to read the attribute information of all the plug-ins, and to determine the effective plug-in, monitor the plug-in update action and the plug-in addition action.

[0101] For this purpose, the plug-in management module monitors the relevant online IDE instances through the creation of the first probe, which has the following technical benefits:

[0102] I. Accurate and comprehensive plug-in information acquisition

[0103] 1. Through the monitoring of the first probe on the online IDE instances running under different underlying editing environments (first underlying editing environment, second underlying editing environment), the attribute information of all plugins can be read. This includes the basic information, version, applicable environment, environment applicable version, and other aspects of the plugin, enabling the plugin management module to comprehensively and deeply understand the specific characteristics and status of each plugin, providing detailed basis for subsequent plugin management, maintenance, and adaptation with the online IDE.

[0104] 2. With the monitoring function of the probe, it can accurately determine which plugins are effective in each online IDE instance. This helps the plugin management module to clearly identify the plugins that are actually in effect in the current development environment, so that when performing plugin-related operations (such as updating, maintenance, etc.), unnecessary operations on ineffective plugins can be avoided, improving the accuracy of plugin management.

[0105] Two, efficient real-time plugin dynamic monitoring

[0106] 1. The first probe can monitor plugin update actions in real time. Once a plugin releases a new version and has an update requirement in an online IDE instance, the plugin management module can learn about this situation in the first time. This enables the plugin to be updated in a timely manner, ensuring that its functionality remains up-to-date and maintaining compatibility with the online IDE, which is beneficial for developers to utilize the latest plugin features and improve development efficiency.

[0107] 2. Similarly, for plugin addition actions, the probe can quickly monitor them. When a developer needs to add a new plugin to a specific online IDE instance, the plugin management module can promptly handle the corresponding processing, such as checking the compatibility of the new plugin with the underlying editing environment and other effective plugins, after obtaining this information through the probe, ensuring that the new plugin can be successfully added and run normally, providing a more convenient way for developers to extend plugins.

[0108] Three, improve the overall stability and compatibility of the system

[0109] 1. Through continuous monitoring of online IDE instances under different underlying editing environments, the plugin management module can better grasp the adaptation between plugins and online IDEs. For potential compatibility issues between plugins and IDEs, measures can be taken to adjust in advance, such as prompting developers to update plugin versions or replace appropriate plugins, thereby avoiding system crashes, abnormal functions, and other problems caused by incompatible plugins and IDEs, enhancing the overall stability of the system.

[0110] 2. Based on the monitoring of the obtained plug-in information and the understanding of the plug-in dynamics, the plug-in management module can more reasonably perform plug-in configuration management. For example, according to the applicable environment and the effective situation of the plug-in, the distribution of the plug-in in different online IDE instances is optimized to ensure that each online IDE instance can run efficiently under appropriate plug-in configuration, thereby improving the compatibility and overall running efficiency of the system.

[0111] IV. Facilitating developers to manage plug-ins

[0112] 1. For developers, the plug-in management module presents plug-in related information such as active plug-ins and plug-in update status through probe monitoring, providing a clear view of plug-in status. Developers can intuitively understand the running status of each plug-in in the system, facilitating them to select, update or delete plug-ins when needed, and improving the convenience of developers to manage plug-ins.

[0113] 2. Since the plug-in management module can timely monitor and handle various dynamic situations of plug-ins, developers do not need to spend a lot of effort to troubleshoot whether the plug-ins need to be updated, whether they are compatible with the environment, etc. This greatly reduces the troubleshooting burden of developers in plug-in management, allowing them to focus more on code development and other core businesses, thereby improving development efficiency.

[0114] In a specific application scenario, the plug-in management module creates a first probe to monitor the online IDE instances running in the first bottom-layer editing environment and the second bottom-layer editing environment of the first online IDE and the second online IDE, thereby realizing the functions of reading attribute information of all plug-ins, determining active plug-ins, monitoring plug-in update actions, and monitoring plug-in addition actions. The technical implementation process can include the following technical processing:

[0115] For the creation and initialization of the probe, according to the monitoring target of the online IDE instance to be achieved, it is clear that the first probe needs to have the functions of reading attribute information of all plug-ins, determining active plug-ins, monitoring plug-in update actions, and monitoring plug-in addition actions. Based on these functional requirements, the specific architecture and implementation method of the probe are planned.

[0116] According to the characteristics of the online IDE involved (such as developed based on a specific programming language or platform) and the underlying editing environment, a suitable technical framework is selected to create the first probe. For example, if the online IDE is developed based on Java and the underlying editing environment has a corresponding Java API available for calling, a Java-related monitoring framework (such as Java Management Extensions-JME) may be selected; if the online IDE involves a web application, a framework suitable for web monitoring (such as Prometheus combined with a related web client library for monitoring various indicators of web services, which can be extended to monitor plug-in related information) may be selected.

[0117] After creating the probe, initialization settings are performed. This includes configuring the connection parameters of the probe with the first online IDE, the second online IDE, such as specifying the network address, port number, authentication information (if required) of the IDE instance, so that the probe can successfully establish a communication connection with the target IDE instance.

[0118] At the same time, the monitoring frequency of the probe is set, that is, how long to perform a comprehensive monitoring of the online IDE instance. This frequency needs to be determined comprehensively according to the performance of the system, the expected frequency of plug-in updates, and the requirements for real-time performance, etc. For example, for a plug-in environment with frequent updates, a shorter monitoring frequency (such as monitoring every 5 minutes) may be set, while for a relatively stable environment, the monitoring interval may be appropriately extended (such as monitoring every 30 minutes).

[0119] For establishing a connection with the online IDE instance, according to the network communication protocol (such as HTTP, HTTPS, RPC, etc.) used by the online IDE instance, the first probe needs to perform corresponding protocol adaptation. If it is an HTTP / HTTPS protocol, the probe may need to send a monitoring request to the IDE instance by constructing appropriate HTTP request headers, request bodies, etc., and handle the response from the IDE instance. For RPC protocol, the probe needs to follow the corresponding RPC call specification and interact with the IDE instance through remote procedure call.

[0120] If the online IDE instance sets authentication and authorization mechanisms (such as username / password login, token authentication, etc.), the probe needs to have the ability to handle these authentication and authorization. It may need to provide correct authentication information (such as sending a username and password or carrying a valid token) according to the requirements of the IDE instance during connection establishment, to obtain legal access rights and ensure that the IDE instance can be monitored.

[0121] For reading plug-in attribute information, once a connection is established with an online IDE instance, the first probe first needs to identify the storage structure of the plug-in under each underlying editing environment (the first underlying editing environment, the second underlying editing environment). Different IDEs and underlying editing environments may have different plug-in storage methods, for example, some may store plug-ins in file form under a specific directory, and some may use a database to store plug-in related information. The probe needs to understand these storage structures in order to accurately find the plug-in and obtain its attribute information.

[0122] For the basic information of the plug-in, such as plug-in name, author, description, etc., the probe may read it from the plug-in's metadata file (such as the manifest file). It extracts the corresponding information according to the pre-defined format by parsing the specific fields in the file. For example, if the manifest file is in JSON format, the probe will use a JSON parsing library to parse the file content and obtain the field value corresponding to the plug-in name as the plug-in name information.

[0123] The version information of the plug-in is usually stored in the version identification area specially set by the plug-in, such as the version number file or the specific constant in the plug-in code. The probe will identify and access these areas to extract the accurate version number. For example, in some IDEs, the plug-in version number may be stored in a file named version.txt, and the probe will read the file content and parse the version number in it.

[0124] For the applicable environment and environment version of the plug-in, the probe will interact with the code part of the plug-in responsible for environment compatibility detection. It may send a specific query request to the plug-in, asking it to return the underlying editing environment types it can adapt to (such as specific versions of VSCode or IntelliJ IDEA, etc.) and the corresponding environment version range information. Through this interaction, the probe can obtain the two attribute information of the plug-in.

[0125] For determining the effective plug-in, the first probe will continuously monitor the running state of the plug-in in the online IDE instance. It judges whether the plug-in is effective by observing whether the plug-in is running, whether there are error messages, whether it has completed the necessary initialization process, etc. For example, if the plug-in has started and there are no error prompts, and it can normally respond to the relevant instructions issued by the IDE instance, it can be preliminarily judged that the plug-in is effective.

[0126] In addition to monitoring the plugin's own running status, the probe also checks the interaction between the plugin and the online IDE instance. If the plugin can correctly receive and process commands issued by the IDE instance and correctly return the processing results to the IDE instance, this is also an important basis for determining whether the plugin is effective. By comprehensively considering the plugin's running status and its interaction with the IDE, the probe can more accurately identify effective plugins.

[0127] To monitor plugin updates, the first probe periodically checks the versions of plugins in the online IDE instance. It obtains the plugin's current version information (using the method described above) and compares it with the previously detected version. If a version number change is detected, it indicates that the plugin has been updated.

[0128] In addition to detecting version changes, the probe also monitors the source of plugin updates. For example, it checks whether a plugin update comes from an officially released new version, a developer's own compilation, or other means. Understanding the update source allows for a better assessment of the update's reliability and security, providing a reference for subsequent update processing.

[0129] To monitor plugin activity, when a new plugin is added to the online IDE instance, the first probe tracks the plugin's installation directory. It detects the plugin's location by monitoring file system changes (such as newly added files or directories) within the IDE instance. Once the installation directory is determined, further monitoring and processing of the new plugin can be performed.

[0130] The probe checks the initialization status of a new plugin after installation. It determines whether the new plugin has been successfully added and is effective by observing whether it has completed the necessary initialization process (such as loading dependencies and setting initial parameters) and whether it can respond correctly to commands issued by the IDE instance. By monitoring the initialization status of new plugins, potential problems during the plugin addition process can be identified and resolved promptly.

[0131] In practical implementation, besides using the first probe to read plugin attribute information, identify active plugins, monitor plugin update actions, and plugin addition actions, the following alternative methods can also achieve the same purpose:

[0132] I. Extending the implementation using the IDE's built-in monitoring and management functions

[0133] Analyze the existing monitoring mechanisms of the IDE:

[0134] Many mature online IDEs (such as Visual Studio Code, IntelliJ IDEA, etc.) have certain built-in monitoring mechanisms for monitoring their own running status, resource occupation, etc. We can analyze the implementation principles and data acquisition methods of these built-in monitoring functions of the IDE in depth to see if they can be extended to monitor the relevant information of the plug-in.

[0135] For example, some IDEs can capture various runtime events through their internal event listening system. We can try to use these event listening mechanisms to capture specific events related to plug-ins, such as plug-in startup events, update events, etc., to determine the active plug-ins and monitor plug-in update actions.

[0136] Extend the IDE management interface:

[0137] IDEs usually provide some management interfaces for external programs or plug-ins to interact with them to achieve functions such as installing and uninstalling plug-ins. We can extend these management interfaces to not only handle basic plug-in management operations, but also return plug-in attribute information, report whether the plug-in is active, and notify the outside about plug-in update and addition actions, etc.

[0138] By adding corresponding function logic to the IDE management interface, such as returning detailed attribute information of the plug-in along with the installation result in the plug-in installation interface (by reading the relevant configuration file or data structure of the plug-in during installation), and continuously obtaining the running status of the plug-in through the interface to determine whether it is active during subsequent running, as well as using the interface to listen to plug-in update and addition actions, etc.

[0139] II. Monitor using proxy server mode

[0140] Set up a proxy server:

[0141] Set up a proxy server between the online IDE instance and the external network (if the plug-in update operation involves external network) or local resources. The proxy server can intercept and analyze all network traffic and access requests to local resources passing through it to obtain information related to the plug-in.

[0142] For example, when the plug-in needs to download updates from an external server, the proxy server can intercept the download request and analyze the plug-in version information, update source, etc. contained in it to monitor the plug-in update action. Similarly, when the plug-in interacts with other local components to obtain resources or perform initialization operations, the proxy server can analyze these interaction requests to understand the running status of the plug-in and determine the active plug-in, etc.

[0143] Configuration of proxy rules and analysis logic:

[0144] For different plugin monitoring needs, corresponding proxy rules and analysis logic need to be configured on the proxy server. For monitoring plugin update actions, rules can be set to let the proxy server focus on specific plugin update-related network ports, protocols, and file download requests. Once traffic that meets these rules is detected, detailed analysis is performed to determine whether it is a plugin update.

[0145] For determining active plugins, the proxy server can determine whether the plugin has completed the necessary initialization process and can normally respond to instructions from the IDE instance based on network traffic characteristics generated when the plugin interacts with the IDE instance (such as frequent request-response patterns, specific instruction interactions, etc.), thereby determining whether the plugin is active.

[0146] For monitoring plugin addition actions, the proxy server can track the installation of new plugins by analyzing local file system access requests generated during the installation process (such as new files, directory creation, etc.) and possible network download requests (if the new plugin needs to download some components from the outside), and check its initialization to determine whether it has been successfully added and activated.

[0147] III. Implementation based on log analysis

[0148] Collect relevant log files:

[0149] Online IDE instances and plugins usually generate various log files during their operation, recording their running conditions, operation history, error information, etc. These log files related to online IDE and plugins can be collected, including the main running log of the IDE, the specific log of the plugin (if there is a separate setting), and the process log that may involve plugin installation, update, etc.

[0150] For example, in some IDEs, the plugin installation process records detailed installation steps, problems encountered, etc. in a special installation log, while the plugin runtime records startup time, running status, interaction with the IDE, etc. in its own running log.

[0151] Parse and analyze log content:

[0152] Parse the collected log files according to different log file formats (such as text format, XML format, etc.) using corresponding parsing methods (such as regular expression parsing, XML parser, etc.) to convert their content into structured data form for analysis.

[0153] Then the monitoring of the plug-in related information is realized by analyzing the structured data. For reading the plug-in attribute information, the records about the plug-in name, author, description, version and other attributes can be found in the plug-in installation log or the running log, although it can not be as accurate as direct acquisition, but it can provide a general understanding.

[0154] For determining the effective plug-in, by analyzing the records about the plug-in startup, running state, interaction with the IDE and the like in the plug-in running log, it is judged whether the plug-in has completed the necessary initialization process and can normally respond to the instructions issued by the IDE instance, so as to determine whether the plug-in is effective.

[0155] For monitoring the plug-in update action, the information about the plug-in version change, update source and the like is found in the plug-in update log (if there is a separate setting) or the main running log of the IDE, so as to monitor the plug-in update action.

[0156] For monitoring the plug-in addition action, the installation process of the new plug-in, whether the necessary initialization process is completed and whether it can normally respond to the instructions issued by the IDE instance are analyzed from the new plug-in installation log, so as to determine whether it is successfully added and effective.

[0157] Optionally, the plug-in management module monitors the plug-in update action and the plug-in addition action through the created plug-in loader, responds to the plug-in update action to update the effective plug-in based on the association relationship, and responds to the plug-in addition action to add the plug-in based on the association relationship, and reloads the effective plug-in in the first online IDE or the second online IDE according to the monitoring result after the first online IDE or the second online IDE is restarted.

[0158] For this purpose, the plug-in management module realizes the related functions through the created plug-in loader, which brings many technical benefits to the online code development system in the aspects of plug-in management, development environment stability, development process optimization and the control of the plug-in by the developer, and the like.

[0159] One, efficient plug-in update and addition management

[0160] 1. The plug-in loader can monitor the plug-in update action and update the effective plug-in based on the association relationship with each plug-in. This ensures that the plug-in can keep up with the new version released by the developer in time, so that the developer can use the latest functions and repaired vulnerabilities of the plug-in to improve the development efficiency. For example, the code formatting plug-in may provide more accurate formatting rules after updating, and the developer can enjoy these improvements in time.

[0161] 2. By monitoring the plug-in addition action and adding plug-ins based on the association relationship, the plug-in loader provides a convenient way for developers to add new plug-ins. Without the need for complex manual configuration processes, developers only need to trigger the addition action, and the plug-in loader can automatically complete the relevant operations to ensure that the new plug-in can be correctly integrated into the development environment, compatible with existing plug-ins and online IDEs, and reduce compatibility problems caused by improper plug-in addition.

[0162] II. Ensuring the stability and continuity of the development environment

[0163] 1. After the first online IDE or the second online IDE is restarted, the plug-in loader reloads the effective plug-ins based on the monitoring results. This allows the effective state of the plug-ins before and after the restart to be continued, so that when the developer enters the development environment again, the plug-ins they rely on can be in the normal working state before, maintaining the consistency of the development environment and avoiding the situation that the development work is affected due to the chaotic state of the plug-ins caused by the restart.

[0164] 2. The plug-in loader handles plug-in updates, additions, and reloads after restart based on its association with the plug-ins and monitoring results. This means it will ensure that the plug-ins are always compatible with the online IDE, avoiding system instability or abnormal plug-in operation caused by compatibility issues, further enhancing the stability of the entire online code development system.

[0165] III. Optimizing development processes and resource utilization

[0166] 1. Developers do not need to spend a lot of time and effort to manually manage plug-in updates, additions, and reloads after IDE restart. The plug-in loader automatically completes these tasks, allowing developers to focus more attention on code development itself, simplifying the development process and improving development efficiency.

[0167] 2. When updating, adding, and reloading plug-ins, the plug-in loader performs precise operations based on the association relationship and monitoring results, avoiding unnecessary resource waste, such as avoiding the situation where system resources are occupied but cannot work normally due to repeated download of existing plug-in versions or loading of incompatible plug-ins. By optimizing these plug-in-related operations, more rational system resource utilization is achieved.

[0168] IV. Facilitating overall control of plug-ins by developers

[0169] 1. The monitoring function of the plugin loader enables developers to clearly understand the update, addition, and reloading of plugins after IDE restart, etc. This provides a clear view of the plugin status for developers, making it easy for them to promptly understand the relevant information of the plugin when needed, and make reasonable decisions, such as deciding whether to further check the functionality of a newly updated plugin.

[0170] 2. Through a series of plugin management functions implemented by the plugin loader, developers can more conveniently control the overall plugin. They can easily update, add, or ensure the normal operation of plugins after restart according to project needs, improving the convenience and effectiveness of plugin management, and thus improving the efficiency of the entire development work.

[0171] In a specific application scenario, the plugin management module can effectively monitor plugin update actions and plugin addition actions through the created plugin loader based on the following technical implementation process, respond to these actions to perform plugin update and addition operations, and reload the effective plugins after IDE restart, ensuring smooth plugin management and stable development environment in the online code development system:

[0172] For the creation and initialization of the plugin loader, the overall architecture of the plugin loader is planned according to the functions to be implemented, such as monitoring plugin update actions and addition actions, and corresponding update, addition, and reloading of plugins after restart. It is clear that it needs to interact with online IDE (first online IDE and second online IDE), plugins, and related monitoring data storage to complete various tasks. For example, it is determined that the plugin loader should have interfaces compatible with different underlying editing environments to accurately operate plugins in corresponding online IDEs. At the same time, the internal data structure is designed to store the association relationship of plugins, monitoring results, and other information to facilitate subsequent processing.

[0173] Based on the technology stack (such as programming language, development framework, etc.) of online IDE and plugins, appropriate technologies are selected to create the plugin loader. If the online IDE is developed based on Java, Java-related libraries and technologies may be selected to build the plugin loader, such as using Java's network communication library to implement interaction with IDE and plugins, and using Java's reflection mechanism to dynamically load and operate plugins, etc.

[0174] For different operating system environments (such as Windows, Linux, etc.), the characteristics and APIs of the operating system need to be considered to ensure that the plugin loader can run stably in the corresponding environment. For example, in the Linux environment, Linux file system operation APIs may be used to handle plugin file storage and reading operations, etc.

[0175] After the plugin loader is created, initialization settings are made. This includes establishing connections with the first online IDE and the second online IDE, configuring connection parameters such as network addresses, port numbers, authentication information (if any), etc., so as to obtain the running status of the IDE and related plugin information in real time. At the same time, the data structure for storing the association relationship of the plugin is loaded and initialized, and the pre-configured plugin and the association relationship data of the available plugin in different underlying editing environment are imported into it, so as to prepare for subsequent plugin operation based on the association relationship.

[0176] For monitoring plugin update actions, the plugin loader sets up a special update monitoring mechanism through the interaction interface with the online IDE and the plugin. This may include periodically sending version query requests to the plugin to inquire about the current version information of the plugin; or listening to the network port where the plugin is located (if the plugin updates through the network), capturing possible update-related network traffic characteristics such as specific update notification packets, etc. For example, for some plugins that update through the HTTP protocol, the plugin loader can periodically send HTTP GET requests to the plugin's update check endpoint to obtain the latest version number of the plugin, and compare it with the locally recorded effective plugin version to determine whether there is an update action.

[0177] When detecting changes in the version of the plugin, the plugin loader not only determines that there is an update action, but also identifies the source of the update. It analyzes update-related network traffic, file download sources (if the plugin updates through file download), etc., to determine whether the update is from an official release of a new version, a developer-compiled update, or other sources. At the same time, the source of the update is verified to ensure the legality and security of the update. For example, for updates from official releases, verify whether the digital signature is correct; for developer-compiled updates, check whether they meet the system's prescribed update process and permission requirements, etc., to prevent malicious updates from causing system failures.

[0178] For monitoring plugin addition actions, the plugin loader tracks the installation process of new plugins by listening to file system changes, network download activities, etc. of the online IDE. When a new plugin is added to the online IDE, it will monitor the newly added file directory (which may be the installation directory of the new plugin) in the IDE, the download request on the network (if the new plugin needs to download some components from the outside) and other situations, so as to determine that there is a new plugin addition action. For example, in a Windows environment, the plugin loader can use the file system monitoring API of Windows to monitor the changes of files and directories under the IDE installation directory, and once a new directory is created and meets the characteristics of plugin installation, it is determined that there is a new plugin addition action.

[0179] In the new plugin installation process, the plugin loader checks the compatibility of the new plugin with the online IDE and the active plugins. It compares the attribute information of the new plugin (such as the applicable environment, dependent libraries, etc.) with the relevant information of the underlying editing environment of the online IDE and the active plugins. For example, it checks whether the minimum required IDE version of the new plugin matches the current online IDE version, whether the libraries dependent on the new plugin already exist in the IDE environment and are compatible in version, etc., to ensure that the new plugin can smoothly integrate into the existing development environment.

[0180] For plugin update in response to the update action, when it is determined that there is a plugin update action and the verification is passed, the plugin loader obtains detailed information of the plugin to be updated based on the stored plugin association relationship, including the specific content of the update, version changes, configurations that may need to be adjusted after the update, etc. For example, through the association relationship, the specific adaptation of the plugin to be updated under different underlying editing environments is found, and it is determined whether the installation path of the plugin in different IDEs, the interaction mode with other plugins, etc. need to be adjusted after the update.

[0181] According to the obtained update information, the plugin loader performs the update operation according to the specification process of the plugin update. This may include downloading the update file (if necessary), replacing the files of the old version plugin, updating the configuration file of the plugin, etc. For example, for a plugin that downloads the update file through the network, the plugin loader will download the update file to the specified directory according to the download link and download method provided by the plugin developer, and then replace the executable files, configuration files, etc. of the old version plugin according to the update requirements to ensure the success of the plugin update.

[0182] For plugin addition in response to the addition action, when the plugin addition action is monitored, the plugin loader prepares the conditions for adding the new plugin based on the association relationship of the plugin. This includes checking whether the resources required by the new plugin exist in the online IDE environment, such as dependent libraries, specific configuration files, etc.; at the same time, determining the installation location and installation method of the new plugin under different underlying editing environments, etc. For example, according to the association relationship of the new plugin, the specific installation path of the new plugin in the first online IDE or the second online IDE is determined, and whether some pre-installed components are required.

[0183] After the addition conditions are met, the plugin loader performs the addition operation according to the established plugin addition process. This may include copying the files of the new plugin to the specified installation path, setting initial parameters, starting the initialization process of the new plugin, etc. For example, the executable file of the new plugin is copied from the download directory to the plugin installation directory of the online IDE, and then the startup parameters of the new plugin are set, and the initialization process of the new plugin is started to ensure that the new plugin can be normally started and run.

[0184] In order to reload the effective plug-in after the IDE restarts, the plug-in loader monitors the restart event of the first online IDE or the second online IDE through the continuous connection with the online IDE. It can be realized in various ways, such as periodically checking the process state of the IDE, and when the process disappears and reappears again and meets the restart characteristics, it is determined that the IDE restarts; or receiving the restart notification signal sent by the IDE (if the IDE has the ability to send such a signal), so as to know the IDE restart condition.

[0185] After learning that the IDE restarts, the plug-in loader immediately obtains the detailed information of the effective plug-in on the IDE before the restart from the stored monitoring data, including the unique identifier of the plug-in, the installation path, the version number, the interaction with other plug-ins, etc. These information is saved through monitoring and recording during the normal operation of the plug-in, and provides accurate data basis for reloading the plug-in.

[0186] According to the obtained plug-in information before the restart, the plug-in loader reloads the effective plug-in according to the normal loading process of the plug-in in the IDE. This may include copying the files of the plug-in to the original installation path (if the location of the plug-in file may change during the restart process), resetting the startup parameters of the plug-in, starting the initialization process of the plug-in, etc. For example, the executable file of the effective plug-in before the restart is copied from the backup directory (if any) to the plug-in installation directory of the online IDE, and then the startup parameters of the plug-in are reset, the initialization process of the plug-in is started, and the plug-in can be restarted and run, and restored to the effective state before the restart.

[0187] Optionally, the online code development system further comprises a configuration management module, the configuration management module is configured to manage first configuration information of the first online IDE and second configuration information of the second online IDE, the first configuration information enables the first online IDE to perform online editing of the first code, and the second configuration information enables the second online IDE to perform online editing of the second code.

[0188] To this end, the configuration management module in the online code development system manages the configuration information of the first online IDE and the second online IDE, which brings the following technical benefits in terms of meeting individualized editing needs, simplifying maintenance processes, ensuring system stability and compatibility, and facilitating version control and configuration migration, etc.

[0189] I. Individual customization and code editing adaptation

[0190] 1. By providing specific first configuration information for the first online IDE to enable efficient online editing of the first code, and providing corresponding second configuration information for the second online IDE to support online editing of the second code. This can achieve personalized configuration according to the characteristics and editing requirements of different types of code (such as front-end code, back-end code, etc.), ensure that each online IDE can carry out editing work of the corresponding code in the most suitable configuration environment, and improve editing efficiency and accuracy.

[0191] 2. Developers can work in the online IDE configuration environment that they are familiar with and well adapted according to the type of code they are responsible for (such as front-end developers for the first code and back-end developers for the second code). This personalized customization helps developers to edit code more comfortably and conveniently, reduces the problems of inconvenience and low efficiency caused by inappropriate configuration, and improves the overall experience of developers.

[0192] II. Configuration unified management and maintenance convenience

[0193] 1. The configuration management module unifies the management of the first configuration information of the first online IDE and the second configuration information of the second online IDE. This avoids the management confusion that may be caused by the dispersion of configuration information in each IDE, so that system administrators or related maintenance personnel can view, modify, backup, etc. all important configuration information in one centralized location, greatly improving the convenience and operability of configuration management.

[0194] 2. When the configuration of the online IDE needs to be updated, adjusted or repaired, since the configuration management module has a clear grasp of the configuration information, the maintenance personnel can quickly locate the specific configuration item that needs to be modified without having to search one by one in the complex setting interface of each IDE. This simplifies the configuration maintenance process, reduces maintenance time and workload, and improves the maintainability of the system.

[0195] III. Ensure system stability and compatibility

[0196] 1. The configuration management module is responsible for ensuring the accuracy and stability of the first configuration information and the second configuration information. During system operation, it can prevent the loss or error of configuration information due to unexpected situations (such as software updates, system failures, etc.), always keep the configuration of each online IDE in the correct and effective state, and maintain the overall stability of the system.

[0197] 2. Through fine management of configuration information, the configuration management module can detect and solve potential configuration compatibility issues in advance. For example, ensure that the first configuration information is compatible with the underlying editing environment and related plugins on which the first online IDE is based. Similarly, the second configuration information is also processed in a similar manner. This helps to avoid IDE running abnormally, plugins not working properly, and other situations caused by configuration incompatibility, enhancing the compatibility of online IDE in different configuration scenarios.

[0198] Four, facilitate version control and configuration migration

[0199] 1. The configuration management module can perform version control on the first configuration information and the second configuration information. This means that different stages of configuration versions can be recorded, making it easy to backtrack to a specific configuration state when needed, such as quickly recovering to a previously stable running configuration version when problems occur, or switching to the appropriate configuration version during development according to project progress, providing a guarantee for the smooth progress of the project.

[0200] 2. When the online IDE needs to be migrated from one environment to another (such as from a test environment to a production environment), the configuration management module can easily migrate the first configuration information and the second configuration information. It can ensure that the online IDE can run normally according to the original configuration requirements in the new environment, reducing the trouble of reconfiguring due to environment migration, and improving the flexibility and portability of the system.

[0201] In a specific application scenario, based on the following detailed technical implementation process, the configuration management module can effectively manage the first configuration information of the first online IDE and the second configuration information of the second online IDE, meeting the configuration management requirements of the online code development system:

[0202] For the storage and organization of configuration information, the configuration management module needs to determine the appropriate storage method to save the first configuration information and the second configuration information. Common storage methods include databases (such as relational databases MySQL, PostgreSQL, or non-relational databases such as MongoDB), configuration files (such as JSON format, XML format, etc.), or repositories based on version control systems (such as Git). For example, if you choose to store in a database, you will design the corresponding database table structure according to the structure and characteristics of the configuration information, and store different parts of the configuration information (such as editor settings, compiler options, debugger configurations, etc.) in different fields or tables to facilitate querying, updating and management. If you use a configuration file, you will organize the configuration information in a certain format specification (such as JSON key-value pairs) for easy reading and modification.

[0203] For the first configuration information and the second configuration information, the configuration management module designs appropriate data structures to represent them. This may involve defining structures, classes, or other data types to encapsulate different types of configuration parameters. For example, for the code editing related configuration of the first online IDE, there may be a structure containing fields such as font size, color theme, code indentation method, etc.; for the compiler options, there may be another structure containing parameters such as target platform, optimization level, etc. Similarly, for the configuration information of the second online IDE, similar structure design is also carried out to accurately reflect the various configuration details required.

[0204] For ease of management and differentiation, the configuration management module classifies and identifies the first configuration information and the second configuration information. It can be classified according to the functional areas of the configuration (such as editing, compiling, debugging, etc.), and each category can be further subdivided into specific configuration items. At the same time, each configuration item is assigned a unique identifier to accurately locate when querying, updating or referencing. For example, the "font size" configuration item in the editing configuration may be identified as "EDITOR_FONT_SIZE", and the "target platform" configuration item in the compiler options may be identified as "COMPI LER_TARGET_PLATFORM", etc., so that each configuration information can be clearly identified and processed in the entire system.

[0205] For the acquisition and setting of configuration information, the configuration management module establishes interaction interfaces with the first online IDE and the second online IDE to enable the acquisition and setting of their configuration information. These interfaces can be implemented based on network communication protocols (such as HTTP, RPC, etc.) or use the plug-in interfaces, APIs, etc. provided by the IDE itself to interact. For example, if the first online IDE provides RESTfu l API for acquiring and updating configuration information, the configuration management module will interact with the first online IDE by sending HTTP requests (such as GET request to acquire configuration information, PUT request to update configuration information), and parse and process the returned results or send corresponding data according to the API specification.

[0206] When the first configuration information of the first online IDE or the second configuration information of the second online IDE needs to be acquired, the configuration management module sends an acquisition request to the corresponding IDE through the above-mentioned interaction interface.

[0207] After the IDE receives the request, it will return the required configuration information according to its internal mechanism (such as extracting configuration information from local configuration files, databases or memory caches, etc.). The configuration management module then parses the returned information according to the pre-designed parsing method (such as JSON parsing, XML parsing, etc.) to convert it into an internal processable structured data form, and stores it in the local cache or data storage area for subsequent use.

[0208] When the first configuration information of the first online IDE or the second configuration information of the second online IDE needs to be set, the configuration management module first organizes the configuration information to be set according to a pre-defined format (such as converting a structure or class instance into a JSON or XML format, etc.) to make it meet the format requirements that the IDE can accept.

[0209] Then the organized configuration information is sent to the corresponding IDE through the interactive interface with the IDE (such as sending an HTTP PUT request or calling the API of the IDE to set the configuration information, etc.). After receiving the setting request, the IDE will apply the new configuration information to its own running environment according to its own internal mechanism (such as updating the local configuration file, the record in the database, etc.), thereby completing the setting operation of the configuration information.

[0210] For the update and maintenance of the configuration information, the configuration management module will continuously monitor whether there is a demand for updating the first configuration information or the second configuration information in the system. This can be achieved in various ways, such as listening to the configuration update request signal issued by the IDE itself (if the IDE has such a function), receiving manual update requests from developers or system administrators (through a specific management interface or command line tool, etc.), or automatically judging whether some configuration items need to be updated according to the progress and needs of the project. For example, when the developer finds that the code editing font size of the first online IDE needs to be adjusted to improve the visibility during the development process, the developer will send an update request to the configuration management module through a specific management interface, and the configuration management module will timely monitor this demand.

[0211] Once the configuration update demand is monitored, the configuration management module will operate according to the pre-prepared update process. First, the configuration information to be updated will be verified to ensure that the new configuration value is reasonable and meets the system requirements (such as the font size cannot exceed a certain value range, etc.). Then, according to the type of update demand (such as partial configuration item update, overall configuration update, etc.), the corresponding update strategy is adopted. If it is a partial configuration item update, only the related configuration item value will be modified, and the updated configuration information will be sent to the corresponding IDE through the interactive interface with the IDE for application; if it is an overall configuration update, the entire configuration information may be re-acquired, organized and sent to the IDE to ensure that the new configuration can be completely and accurately applied to the running environment of the IDE.

[0212] The configuration management module establishes a backup and recovery mechanism for configuration information. Before each update to the first configuration information or the second configuration information, the current configuration information is backed up and stored in a designated backup location (such as another database table, a backup file, etc.). When problems occur (such as abnormal operation of the IDE after updating, loss of configuration information, etc.), the previous configuration state can be quickly restored based on the backup information. For example, if code editing errors are found after updating the configuration information of the first online IDE, the configuration before the update can be quickly restored through the recovery mechanism, avoiding the impact on the normal development work.

[0213] The configuration management module performs version control on the first configuration information and the second configuration information, assigning a unique version number to each configuration update. This version number can be a numerical number (such as 1.0, 1.1, etc.) or other forms (such as timestamp + serial number, etc.), to facilitate identification and differentiation of configuration states at different times. At the same time, detailed information of each configuration update is recorded, including update time, update content (such as which configuration items are updated), update reason (such as to adapt to new project requirements, fix a certain problem, etc.), etc., forming a configuration update log, which can be reviewed when needed.

[0214] When switching between different configuration versions is needed, the configuration management module obtains the corresponding version of configuration information according to the requirements. If switching from the current version to a past version is needed, the corresponding version information is found from the backup storage location (such as a database table, a backup file, etc.), and is re-applied to the corresponding IDE according to the above-mentioned process of obtaining and setting configuration information, so that it returns to the configuration state of that version. For example, if it is found during project development that the current configuration version causes some problems and needs to be switched to a previous stable version, the configuration management module will find the information of that version by querying the configuration update log, and then re-apply it to the first online IDE or the second online IDE, to solve the problem and restore normal development.

[0215] For configuration information migration, when the first configuration information of the first online IDE and the second configuration information of the second online IDE need to be migrated from one environment (such as a test environment) to another environment (such as a production environment), the configuration management module first analyzes the differences between the two environments, including operating system differences, network setting differences, resource configuration differences, etc. For example, the test environment may be running on a local development machine, while the production environment may be running on a cloud server. The configuration management module needs to analyze the differences in hardware, software, and network between the two environments, so as to make corresponding adjustments during the migration process.

[0216] According to the result of the environment difference analysis, the configuration management module formulates a corresponding migration process. Generally, the first configuration information and the second configuration information are first extracted from the storage mode (such as a database, a configuration file, etc.) of the source environment, and are arranged according to the requirements of the target environment (such as adjusting network setting related configuration items, modifying compiler options according to resource configuration, etc.). Then, the arranged configuration information is sent to the first online IDE and the second online IDE in the target environment according to the interaction mode (such as through a new HTTP request format, adapting to a new API, etc.) of the IDE in the target environment, so that the first online IDE and the second online IDE can normally operate according to the migrated configuration information.

[0217] Optionally, the configuration management module monitors the online IDE instances of the first online IDE and the second online IDE running in the first underlying editing environment and / or the second underlying editing environment through the created second probe, to determine at least one of the first configuration information of the first online IDE, the second configuration information of the second online IDE, whether the first online IDE is restarted, whether the second online IDE is restarted, and whether the second probe is adapted to at least one of the first underlying editing environment and / or the second underlying editing environment and a version thereof.

[0218] To this end, the configuration management module monitors the relevant online IDE instances through the created second probe, which has the following technical benefits in terms of accurate configuration information acquisition, real-time monitoring of IDE running status, ensuring environment adaptation and compatibility, and facilitating developer and administrator operation, etc.:

[0219] I. Accurate configuration information acquisition and management

[0220] 1. By monitoring the online IDE instances running in different underlying editing environments (the first underlying editing environment and / or the second underlying editing environment) through the second probe, the first configuration information of the first online IDE and the second configuration information of the second online IDE can be accurately determined. This enables the configuration management module to understand the specific configuration status of each online IDE in real time, providing accurate basis for subsequent configuration adjustment, update, and ensuring that the configuration matches the running requirements of the IDE, etc., avoiding management confusion caused by inaccurate or unclear configuration information.

[0221] 2. As the development process progresses, the configuration of the online IDE may change due to various reasons (such as changes in project requirements, installation or update of plugins, etc.). The continuous monitoring of the second probe can timely capture the dynamic changes of these configuration information, so that the configuration management module can make corresponding adjustments to ensure that the configuration always remains in an optimal state to support the efficient operation of the online IDE, and improve the adaptability of the entire online code development system to different development scenarios.

[0222] II. Real-time monitoring of IDE running status

[0223] 1. The first online IDE and the second online IDE can be monitored for restarts, which is crucial for the configuration management module. Because IDE restarts can affect the configuration of applications and their effectiveness, by promptly learning about the restart event, the configuration management module can quickly check after the restart whether the configuration is correctly loaded, whether additional configuration recovery or adjustment operations are needed, etc., ensuring the continuity and effectiveness of the online IDE configuration before and after the restart, and maintaining the stability of the development environment.

[0224] 2. Knowing the restart status of the IDE and real-time configuration information helps system administrators or configuration management modules allocate system resources (such as memory, CPU, etc.) reasonably based on the actual running status of the IDE. For example, if a certain online IDE frequently restarts and has high configuration requirements, it may need to be allocated more resources to ensure its stable operation, thereby improving the rationality and efficiency of system resource utilization.

[0225] III. Ensuring environment adaptation and compatibility

[0226] 1. The second probe is adapted to at least one of the first underlying editing environment and / or the second underlying editing environment and its version, which ensures that the monitoring process can be accurately and correctly carried out in the corresponding environment. It can effectively avoid the failure or inaccuracy of monitoring caused by the incompatibility of the monitoring tool and the underlying editing environment, ensuring that the configuration management module can obtain real and reliable data about the configuration information, running status, etc. of the online IDE, thereby enhancing the compatibility of the entire online code development system under different underlying editing environments and versions.

[0227] 2. Through monitoring of the online IDE instance under a specific underlying editing environment and version, the configuration management module can discover potential compatibility problems in configuration and environment, plug-ins and environment, etc. For example, if it is monitored that a plug-in update causes the configuration information of the first online IDE to be incompatible with the current underlying editing environment, the configuration management module can take timely measures (such as adjusting the configuration, prompting the developer to replace the plug-in, etc.) to solve the problem, avoiding system failures or development work being hindered due to compatibility problems, and improving the stability and reliability of the system.

[0228] IV. Facilitating developer and administrator operations

[0229] 1. For developers and system administrators, the second probe monitors the presented configuration information, restart status, and other data about the online IDE, providing them with a clear view of the online IDE running. They can intuitively understand the actual running status of each online IDE, making it convenient for them to adjust the configuration, troubleshoot, and other operations when needed, improving their convenience and effectiveness in managing the online IDE.

[0230] 2. Since the configuration management module can monitor and handle various situations of the online IDE through the second probe in a timely manner, developers and administrators do not need to spend a lot of effort to check the configuration status, whether to restart, and other issues of the IDE one by one. This greatly reduces their troubleshooting workload in managing the online IDE, allowing them to focus more on core development work or other important matters in system management, improving overall work efficiency.

[0231] In a specific application scenario, the configuration management module can achieve the functions of determining the first configuration information of the first online IDE and the second configuration information of the second online IDE, detecting whether the first online IDE is restarted and whether the second online IDE is restarted, and ensuring that the second probe is adapted to the first underlying editing environment and / or the second underlying editing environment and their versions, by creating a second probe to monitor the online IDE instances of the first online IDE and the second online IDE running in the first underlying editing environment and / or the second underlying editing environment, respectively, through the following technical process:

[0232] For the creation and initialization of the second probe, according to the monitoring target of the instances of the first online IDE and the second online IDE running in different underlying editing environments, it is clear that the second probe needs to have the functions of determining the configuration information of each online IDE, detecting whether to restart, and adapting to the corresponding underlying editing environment and its version. Based on these functional requirements, the specific architecture and implementation of the second probe are planned. For example, it is determined that the second probe needs to be able to establish a communication connection with different online IDE instances, accurately obtain their internal configuration-related data structures, and real-time perceive the running state changes of the IDE instances to judge whether to restart, etc.

[0233] According to the characteristics of the online IDE (such as developed based on a specific programming language or platform) and the underlying editing environment involved, appropriate technical frameworks and tools are selected to create the second probe.

[0234] If the online IDE is developed based on Java and the underlying editing environment has corresponding Java API available for calling, a Java-related monitoring framework (such as Java Management Extensions - JME) combined with a specific network communication library (such as Apache HttpClient for establishing a network connection with the IDE instance) can be selected to implement the probe function. For a web-based online IDE, a framework suitable for web monitoring (such as Prometheus combined with a related web client library for monitoring various indicators of web services, which can be extended to monitor online IDE-related information) can be selected. At the same time, considering the need to adapt to different underlying editing environments and their versions, a technology with good compatibility and extensibility needs to be selected to allow appropriate adjustments and configurations according to the specific environment.

[0235] After creating the second probe, initialization settings are performed. This includes configuring the connection parameters of the probe with the first online IDE and the second online IDE, such as specifying the network address, port number, authentication information (if required) of the IDE instance, so that the probe can successfully establish a communication connection with the target IDE instance. The monitoring frequency of the probe also needs to be set, i.e., how long to perform a comprehensive monitoring of the online IDE instance. This frequency needs to be determined comprehensively according to the performance of the system, the expected frequency of changes in IDE configuration, and the requirements for real-time performance, etc. For example, for an online IDE with relatively stable configuration, a longer monitoring interval (such as monitoring every 30 minutes) can be set; while for an online IDE that may frequently update configuration or restart, a shorter monitoring frequency (such as monitoring every 5 minutes) may be required.

[0236] For establishing a connection with the online IDE instance, according to the network communication protocol (such as HTTP, HTTPS, RPC, etc.) used by the online IDE instance, the second probe needs to perform corresponding protocol adaptation. If it is HTTP / HTTPS protocol, the probe may need to construct appropriate HTTP request headers, request bodies, etc. to send monitoring requests to the IDE instance and handle responses from the IDE instance. For RPC protocol, the probe needs to follow the corresponding RPC call specification and interact with the IDE instance through remote procedure call. For example, if the first online IDE uses HTTP protocol for internal communication and external service, the second probe needs to construct a request according to the HTTP protocol specification, including the correct request method (such as GET, POST, etc.), request path (pointing to the relevant endpoint for obtaining configuration information or checking restart status, etc.), and necessary request parameters, to accurately obtain the required information.

[0237] If the online IDE instance is set up with authentication and authorization mechanisms (such as username / password login, token authentication, etc.), the second probe needs to handle these authentication and authorization requirements. It may need to provide the correct authentication information (such as sending a username and password or carrying a valid token) during the connection establishment phase, as required by the IDE instance, to obtain legitimate access rights and ensure that it can monitor the IDE instance.

[0238] To determine the first configuration information of the first online IDE, once a connection is established with the first online IDE instance, the second probe first needs to identify the configuration information storage structure of the first online IDE in the first underlying editing environment. Different online IDEs and underlying editing environments may have different configuration information storage methods, such as some may store configuration information in file form under a specific directory, and some may use a database to store configuration-related information. The probe needs to understand these storage structures in order to accurately find the configuration information and obtain its content. For example, some online IDEs may store editing environment-related configurations in a file named config.xml, while compiler options and other configurations may be stored in another file named compiler.cfg. The second probe needs to determine the location and storage format of these configuration files by analyzing the file system structure of the IDE or querying the relevant database tables (if a database is used for storage).

[0239] According to the identified configuration information storage structure, the second probe uses the corresponding method to obtain the configuration information content. If the configuration information is stored in a file, the probe may use file reading operations (such as using a regular text reading function for text format files and a specific binary reading function for binary format files) to read the file content, and parse it according to the file format (such as XML, JSON, etc.) to extract the relevant configuration information. For example, for editing environment configuration information stored in the config.xml file, the second probe will use an XML parser to parse the file content and obtain the values of specific configuration parameters such as font size, color theme, code indentation method, etc. If the configuration information is stored in a database, the probe will send SQL query statements (according to the database type and table structure design) to obtain the required configuration information records and convert them into a processable structured data form.

[0240] For determining the second configuration information of the second online IDE, similar to the first configuration information of the first online IDE, the second probe needs to identify the configuration information storage structure of the second online IDE in the second underlying editing environment after establishing a connection with the second online IDE instance. Similarly, different IDEs and underlying editing environments can lead to different storage methods, and the probe needs to determine the configuration file location and storage format, etc. through analysis or query. Then, according to the identified storage structure, the corresponding method is used to obtain the second configuration information content. For example, if the second online IDE stores its configuration information in a JSON format file, the second probe will use a JSON parser to parse the file content and obtain the values of specific configuration parameters such as plug-in configuration, debugger settings, etc.

[0241] For detecting whether the first online IDE is restarted, the second probe monitors the state changes of the first online IDE process by interacting with the operating system or runtime environment where the first online IDE instance is located. It can periodically check the existence, running state (such as whether it is running, paused, terminated, etc.), and process ID of the first online IDE process. For example, in a Linux environment, the second probe can use Linux process management tools (such as the ps command) or related process monitoring APIs to obtain the state information of the first online IDE process. If the first online IDE process is found to exist before but now disappears, and then a process with similar characteristics (such as the same executable file name, similar startup parameters, etc.) reappears, it can be preliminarily judged that the first online IDE has been restarted.

[0242] In addition to monitoring process state changes, the second probe can also analyze the log files or related event records of the system where the first online IDE is located to assist in determining whether it has been restarted. Many operating systems and online IDEs themselves will record some important running events such as startup, stop, restart, etc. in the system log.

[0243] The second probe will search these log files (according to the log storage location and format of different operating systems and IDEs) to find the restart-related records about the first online IDE. For example, in a Windows environment, it may search for startup and stop event records about the first online IDE in the Windows Event Viewer, and determine whether a restart has occurred by analyzing the time sequence and content of these records.

[0244] For detecting whether the second online IDE restarts, similar to detecting whether the first online IDE restarts, the second probe judges whether to restart by monitoring the state changes of the second online IDE process and analyzing the log files or related event records of the system it is in. It regularly checks the existence, running state, and process ID of the second online IDE process, searches the corresponding system log files or event records for restart-related records about the second online IDE, and determines whether a restart has occurred by comprehensively analyzing these information.

[0245] For ensuring that the second probe is adapted to the underlying editing environment and its version, when creating and initializing the second probe, the first underlying editing environment and / or the second underlying editing environment and its version need to be detected. This can be achieved in various ways, such as querying the version information of the IDE itself (usually by sending a specific query request to the IDE or reading the metadata file of the IDE), or by interacting with the specific API of the underlying editing environment to obtain relevant version information. According to the detected environment and its version information, the second probe will perform corresponding adaptation operations. For example, if it is found that the underlying editing environment is based on a certain version of VSCode, and it is known that this version has some specific API changes or features, the second probe will adjust its internal code logic and communication methods, etc., to ensure that it can accurately monitor operations in this environment.

[0246] As the underlying editing environment and its version are updated, the second probe needs to have the ability to dynamically update to maintain its adaptability and compatibility. This may involve regularly checking for environment version updates (by methods similar to those described above to obtain version information), and adjusting the code logic, communication protocols, etc. of the probe itself according to the update. For example, when the underlying editing environment is upgraded from one version to another, and some new APIs or feature changes occur, the second probe will update its own code in time, use new APIs or adjust communication methods, etc. to ensure that it can still accurately monitor operations in the new environment version, maintaining its adaptability to the underlying editing environment and its version.

[0247] In addition to creating a second probe to achieve the functions of determining the configuration information of the online IDE, detecting whether to restart, and ensuring adaptation to the underlying editing environment and its version, the following equivalent alternative means can also be used:

[0248] I. Extension implementation using IDE built-in monitoring and feedback mechanisms

[0249] 1. Many online IDEs have built-in monitoring and feedback mechanisms to monitor their own running status, resource usage, and other conditions. You can deeply study the implementation principles and data output methods of these built-in mechanisms to see if you can obtain the required configuration information, restart status, and other related content. For example, some IDEs record detailed configuration change history and timestamps for each start and stop in their internal logs. By parsing these log contents, you can obtain configuration information about the IDE and whether it has restarted.

[0250] 2. If the existing feedback mechanism of the IDE cannot directly provide complete required information, you can consider extending and developing the feedback interface of the IDE. By adding custom code modules (possibly in the form of plugins) inside the IDE, you can make it output more comprehensive information according to specific formats and requirements, including detailed configuration information and real-time restart status, etc. For example, develop a special configuration information feedback plugin that can read the configuration parameters of various modules inside the IDE and organize them into a format that is easy to obtain and analyze externally. Output through the existing plugin interface or a newly added specific interface to achieve the function of obtaining configuration information. For detecting the restart status, you can set a timer in the plugin to periodically check the process state of the IDE and feedback the restart status through the interface.

[0251] Two, monitoring and analysis based on proxy server

[0252] 1. Set up a proxy server on the interaction path between the online IDE and external networks or local resources. The proxy server can intercept and analyze all network traffic and access requests to local resources passing through it to obtain information related to the online IDE, including configuration information, whether it has restarted, etc. For example, when the online IDE starts, it may download some configuration files or plugin resources from a remote server. The proxy server can intercept these download requests and analyze the configuration-related information (such as configuration file content, version number, etc.) contained in them to obtain part of the configuration information. Similarly, when the IDE restarts, there may be some network activities related to the restart (such as reconnecting to some services, loading new resources, etc.). The proxy server can analyze the network traffic characteristics of these activities to determine whether the IDE has restarted.

[0253] 2. For different monitoring requirements, corresponding analysis rules and logic need to be configured on the proxy server. For obtaining configuration information, rules can be set to let the proxy server focus on specific configuration file download requests, configuration-related API calls, and other network activities. Once traffic that meets these rules is detected, detailed analysis is performed to extract configuration information. For detecting whether the IDE is restarted, the proxy server can set corresponding judgment logic based on the different network traffic patterns during normal runtime and restart of the IDE (such as the characteristics of a large number of network connection establishments or disconnections for a short time during restart). By analyzing the changes in network traffic, the proxy server can determine whether the IDE is restarted.

[0254] III. Implementation through system log analysis

[0255] 1. Collect various system logs generated by the operating system where the online IDE is located and the IDE itself. These logs may contain detailed information about the operation of the IDE, such as configuration change records, start and stop times, error information during operation, etc. For example, in a Linux environment, system logs are usually stored in multiple files under the / var / log directory, such as sys log, messages, etc. Records related to the online IDE need to be filtered from these logs. The IDE itself may also have its own log files, such as the ide.log file in a specific directory, which may record more detailed information about the configuration and running state.

[0256] 2. Parse the collected system logs according to the format of different log files (such as text format, XML format, etc.) using corresponding parsing methods (such as regular expression parsing, XML parser, etc.) to convert their contents into structured data that can be analyzed. By analyzing this structured data, monitoring of the online IDE can be achieved. For obtaining configuration information, records about configuration changes can be found in the logs, such as modification time and content of configuration parameters, to construct the current configuration information. For detecting whether the IDE is restarted, the timestamps of the IDE start and stop records in the logs can be used to determine whether there are consecutive start and stop records to determine whether the IDE is restarted.

[0257] Optionally, the configuration management module reads the first configuration information and / or the first configuration information through the created configuration loader and records them, and reads the restart status of the first online IDE or the second online IDE and records it, so as to automatically load the corresponding first configuration information or second configuration information after the first online IDE or the second online IDE is successfully restarted.

[0258] To this end, the configuration management module implements relevant functions through the created configuration loader, bringing the following technical benefits in terms of improving configuration management efficiency, ensuring configuration continuity, simplifying developer operations, and facilitating system management and maintenance, etc.

[0259] I. Efficiency and accuracy of configuration management

[0260] 1. The configuration loader can read and record the first configuration information and / or the second configuration information, ensuring that the system has accurate and detailed knowledge of the configuration status of the online IDE. This allows subsequent management, maintenance, and troubleshooting operations to be performed based on these accurate recorded configuration information, avoiding problems caused by unclear or inaccurate configuration information.

[0261] 2. By reading and recording the restart status of the first online IDE or the second online IDE, the configuration management module can understand the running state changes of the IDE in real time. This is very important for timely discovery of potential problems, assessment of system stability, and reasonable arrangement of subsequent operations (such as configuration loading after successful restart), and helps to maintain the normal operation of the system.

[0262] II. Ensure the continuity and effectiveness of the configuration

[0263] 1. After the first online IDE or the second online IDE restarts successfully, the configuration loader can automatically load the corresponding first configuration information or second configuration information. This function ensures the continuity of the configuration before and after the restart, allowing the online IDE to quickly recover to the previous working state after the restart without the need for manual reconfiguration, greatly improving development efficiency and reducing running problems caused by configuration errors or omissions.

[0264] 2. The process of automatic configuration loading is based on accurate recorded configuration information and real-time understanding of the restart status, which ensures that the loaded configuration matches the actual needs of the IDE, avoiding system instability caused by incompatible or incorrect configurations. This maintains the stability of the entire online code development system and ensures that developers can work in a stable environment.

[0265] III. Simplify the operation of developers

[0266] 1. Developers do not need to spend time and effort to reconfigure parameters after the IDE restarts, and the configuration loader will automatically complete the configuration loading. This simplifies the operation process of developers, allowing them to focus more attention on code development itself and improving development efficiency.

[0267] 2. For developers, this mechanism of automatic loading configuration provides a convenient user experience. They can restart the IDE more confidently, knowing that the system will automatically recover to the appropriate configuration state after restarting, without worrying about the tedious configuration-related matters, thereby improving the overall satisfaction of the online code development system.

[0268] IV. Facilitating system management and maintenance

[0269] 1. The configuration management module records and manages the configuration information and restart conditions uniformly through the configuration loader, facilitating centralized monitoring and management by system administrators. Administrators can quickly understand the configuration state of the system and the running status of the IDE by viewing relevant records, promptly discovering and solving possible problems, and improving the convenience and efficiency of system management.

[0270] 2. In the event of system failure or configuration abnormalities, accurate records of configuration information and restart conditions can provide important evidence for troubleshooting. Administrators can analyze the problem based on these records and quickly recover to a normal configuration state through the automatic loading function of the configuration loader, shortening the troubleshooting and recovery time and reducing the impact of system failure on development work.

[0271] In a specific application scenario, the following technical implementation process can be used to achieve that the configuration management module can effectively read and record the first configuration information and / or the second configuration information, read and record the IDE restart conditions, and automatically load the corresponding configuration information after the IDE restarts successfully through the created configuration loader, ensuring smooth configuration management and stable development environment in the online code development system:

[0272] For the creation and initialization of the configuration loader, the overall architecture of the configuration loader is planned according to the functions to be achieved, such as reading and recording the first configuration information and / or the second configuration information, reading and recording the IDE restart conditions, and automatically loading the corresponding configuration information after the IDE restarts successfully. It is clear that it needs to interact with the online IDE (the first online IDE and the second online IDE) and the configuration information storage medium (such as a database, a configuration file, etc.) to complete various tasks. For example, it is determined that the configuration loader should have interfaces compatible with different underlying editing environments to accurately obtain and set relevant configuration information. At the same time, the internal data structure is designed to store configuration information, restart condition records, etc., for subsequent processing.

[0273] Based on the online IDE and the technology stack (such as programming languages, development frameworks, etc.) based on the configuration information, select the appropriate technology to create a configuration loader. If the online IDE is developed based on Java, Java-related libraries and technologies may be selected to build the configuration loader, such as using Java's network communication library to implement interaction with the IDE and configuration information storage medium, using Java's reflection mechanism to dynamically load and operate configuration information, etc.

[0274] For different operating system environments (such as Windows, Linux, etc.), the operating system-related features and APIs also need to be considered to ensure that the configuration loader can run stably in the corresponding environment. For example, in the Linux environment, the Linux file system operation API may be used to handle configuration file storage and reading operations.

[0275] After creating the configuration loader, perform initialization settings. This includes establishing a connection with the first online IDE and the second online IDE, configuring connection parameters such as network addresses, port numbers, authentication information (if any) to enable real-time acquisition of IDE running status and related configuration information. At the same time, initialize the data structure used to store configuration information and restart condition records, such as creating appropriate arrays, linked lists, hash tables, etc. data structure and set the initial value to empty or default value, to prepare for subsequent record and processing operations.

[0276] For reading and recording the first configuration information and / or the second configuration information, the configuration loader first needs to determine the storage location of the first configuration information and / or the second configuration information. This may vary depending on the implementation of the online IDE, for example, the configuration information may be stored in a configuration file in a specific directory of the local file system (such as in JSON format or XML format), or it may be stored in a database on a remote server (such as MySQL, PostgreSQL, etc.).

[0277] Through interaction with the online IDE (such as asking the IDE about the storage location of the configuration information, or determining according to the default settings of the IDE), and understanding of the system environment, the configuration loader finds the accurate configuration information storage location.

[0278] According to the storage method of the configuration information, the configuration loader uses the corresponding reading method. If the configuration information is stored in a file, for example, in JSON format, the configuration loader will use a JSON parsing library to read the file content, and convert the parsed configuration information into an internal processable structured data form (such as Java objects, Python dictionaries, etc.).

[0279] If the configuration information is stored in a database, the configuration loader establishes a connection with the database using a database connection library (such as JDBC for Java, SQLAlchemy for Python, etc.), and then obtains the required configuration information by sending a SQL query statement (designed according to the database table structure and the configuration information to be obtained), and converts it into an internal processable structured data form.

[0280] Once the configuration information is obtained, the configuration loader records it in a pre-initialized data structure. For example, if a hash table is used to store the configuration information, a certain key attribute of the configuration information (such as the configuration item name, IDE name, etc.) is used as the key, and the entire configuration information is stored as the value in the hash table. In this way, when subsequent configuration information needs to be queried, updated or used, accurate configuration information can be easily obtained from the data structure, and the management and maintenance of the configuration information are also facilitated.

[0281] For reading and recording the restart situation of the first online IDE or the second online IDE, the configuration loader monitors the restart event of the first online IDE or the second online IDE through continuous connection with the online IDE. It can be implemented in various ways, such as periodically checking the process state of the IDE, and when the process disappears and reappears and meets the restart characteristics, it is determined that the IDE has restarted; or receiving a separate restart notification signal sent by the IDE (if the IDE has the ability to send such a signal), so as to know the IDE restart situation. For example, in a Windows environment, the configuration loader can use the process management API of Windows to periodically check the process state of the online IDE to monitor whether it has restarted.

[0282] When the IDE restart event is detected, the configuration loader records the restart situation in a data structure specially used to store the restart situation record. This data structure can be a simple array, where each element records the relevant information of a restart event, such as the restart time, IDE name, and whether the restart is successful. For example, the restart situation of the first online IDE is recorded as an array element, which contains the restart time stamp, "first online IDE" as the IDE name, and the mark of whether the restart is successful (such as "true" for success and "false" for failure) according to the actual situation detected.

[0283] For automatically loading corresponding configuration information after the IDE restarts successfully, the configuration loader, after learning that the IDE has restarted, first confirms whether the restart is successful according to the recorded restart condition data structure. It looks up the restart record of the corresponding IDE (the first online IDE or the second online IDE) to check the restart success flag therein. If the flag is "true", it indicates that the restart is successful, and the subsequent configuration loading operation can be performed. For example, the restart record of the first online IDE is found from the array storing the restart condition records. If the restart success flag therein is "true", the next operation is continued.

[0284] Once it is confirmed that the restart is successful, the configuration loader acquires the corresponding configuration information from the data structure storing the configuration information according to the name of the IDE (the first online IDE or the second online IDE). For example, if the first online IDE restarts successfully, the entire content of the first configuration information is acquired from the data structure (such as a hash table) storing the first configuration information, and is converted into a format applicable to the IDE (such as converting the internal structured data into a JSON format or an XML format according to the requirements of the IDE).

[0285] Finally, the configuration loader loads the acquired configuration information into the IDE that has restarted successfully. This can involve the interactive interface with the IDE (such as sending the configuration information to the IDE by sending an HTTP PUT request, or calling the API of the IDE for setting the configuration information, etc.), and applying the configuration information to the running environment of the IDE according to the setting procedure of the IDE. For example, through the RESTful API provided by the IDE, the configuration loader sends the configuration information to the IDE in the JSON format. After the IDE receives it, it applies the new configuration information to its own running environment according to its own internal mechanism (such as updating the local configuration file, the record in the database, etc.), thereby completing the loading operation of the configuration information.

[0286] Figure 2 A structure diagram of a loader module according to an embodiment of the present application is shown in FIG. 1. As shown in FIG. 1, the plug-in management module is connected with the first online IDE for online editing of the first code and having the first underlying editing environment, and the second online IDE for online editing of the second code and having the second underlying editing environment, to have an associated relationship with all the plug-ins available in the first underlying editing environment and the second underlying editing environment, and to manage the plug-ins according to at least one of the following manners: Figure 2

[0287] monitoring the first underlying editing environment of the first online IDE and the second underlying editing environment of the second online IDE to determine the effective plug-ins;

[0288] ​Monitor plugin update actions and plugin addition actions. When a plugin update action is detected, update the active plugins based on the association relationship. When a plugin addition action is detected, add the plugin based on the association relationship. The first underlying editing environment is different from the second underlying editing environment.

[0289] Optionally, the plugin management module includes a plugin reader, which is used to read the attribute information of all plugins, and when the attribute information reading fails, to create an independent verification instance to run the plugin corresponding to the failed reading and obtain the attribute information of the corresponding plugin based on the running result.

[0290] Optionally, the plugin management module includes a first probe, which monitors the online IDE instances running in the first underlying editing environment and the second underlying editing environment, respectively, to read the attribute information of all plugins, identify plugins that have taken effect, and monitor plugin update and plugin addition actions.

[0291] Optionally, the plugin management module includes a plugin loader, which is used to monitor plugin update actions and plugin addition actions, respond to the plugin update actions to update the active plugins based on the association, and respond to the plugin addition actions to add plugins based on the association, and reload the active plugins on the first online IDE or the second online IDE according to the monitoring results after the first online IDE or the second online IDE is restarted through the created plugin loader.

[0292] Figure 3 This is a schematic diagram of the structure of a loader module according to an embodiment of this application. Figure 3 As shown above, in the above Figure 2 Based on the embodiments, the loader module further includes a configuration management module, which is used to manage the first configuration information of the first online IDE and the second configuration information of the second online IDE. The first configuration information enables the first online IDE to perform online editing of the first code, and the second configuration information enables the second online IDE to perform online editing of the second code.

[0293] Optionally, the configuration management module comprises a second probe, configured to monitor the online IDE instance of the first online IDE and the second online IDE running in the first underlying editing environment and / or the second underlying editing environment respectively, to determine at least one of the following: the first configuration information of the first online IDE, the second configuration information of the second online IDE, whether the first online IDE is restarted, and whether the second online IDE is restarted.

[0294] Optionally, the configuration management module further comprises a configuration loader, configured to read and record the first configuration information and / or the first configuration information from the second probe, and read and record the restart of the first online IDE or the second online IDE, to automatically load the corresponding first configuration information or second configuration information after the first online IDE or the second online IDE is successfully restarted.

[0295] An embodiment of the present application is a computer storage medium, which stores a computer executable program. When the computer executable program is run, a set of plug-in management logic is implemented to interact with a first underlying editing environment and a second underlying editing environment to perform plug-in management editing in the following manner:

[0296] monitoring the first underlying editing environment and the second underlying editing environment to determine the effective plug-ins, monitoring plug-in update actions and plug-in addition actions, responding to the plug-in update actions to update the effective plug-ins based on the association relationship, and responding to the plug-in addition actions to add plug-ins based on the association relationship;

[0297] The first online IDE, the second online IDE, and the plug-in management module, the first online IDE is configured to perform online editing of a first code, the first online IDE has the first underlying editing environment to perform online editing of the first code, the second online IDE has the second underlying editing environment to perform online editing of a second code, and the first underlying editing environment is different from the second underlying editing environment.

[0298] The exemplary description of the plug-in management module and the computer storage medium described above can refer to the description above Figure 1 , which will not be repeated here.

[0299] It should be noted that the same or similar parts among various embodiments in the present specification can be mutually referred to, and each embodiment focuses on the differences from other embodiments. In particular, for the device and system embodiments, since they are basically similar to the method embodiments, they are described more simply, and the relevant parts can be referred to the part of the method embodiments. The above-described device and system embodiments are merely illustrative, wherein the modules described as separate components can or can not be physically separated, the components indicated as modules can or can not be physical modules, i.e., can be located in one place or distributed to multiple network modules. Part or all of the modules can be selected according to actual needs to achieve the purpose of the present embodiment. Those skilled in the art can understand and implement without creative labor.

[0300] The above describes only one specific implementation of the present application, but the protection scope of the present application is not limited to this. Any skilled person in the art can easily think of changes or replacements within the technical range disclosed by the present application, which should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. An online code development system, characterized in that, The system includes a first online IDE, a second online IDE, and a plugin management module. The first online IDE is used for online editing of first code and has a first underlying editing environment for this purpose. The second online IDE is used for online editing of second code and has a second underlying editing environment for this purpose. The first underlying editing environment is different from the second underlying editing environment. The plugin management module is connected to both the first and second online IDEs and is associated with all available plugins in both the first and second underlying editing environments in the following manner. At least one of the following is used for plugin management: monitoring the first and second underlying editing environments to identify active plugins, monitoring plugin update actions and plugin addition actions, responding to the plugin update actions to update active plugins based on the association, and responding to the plugin addition actions to add plugins based on the association; the plugin management module is also used to read the attribute information of all plugins to maintain all plugins; the plugin management module is also used to reload active plugins on the first or second online IDE based on the monitoring results after the first or second online IDE restarts.

2. The online code development system according to claim 1, characterized in that, The attribute information includes: the basic information of the plugin, the version of the plugin, the applicable environment of the plugin, and the applicable version of the plugin in the environment. If the attribute information reading fails, an independent verification instance will be created to load the plugin corresponding to the attribute information reading failure onto the independent verification instance and run it. Based on the running result, the attribute information of the corresponding plugin will be obtained.

3. The online code development system according to claim 2, characterized in that, The plugin management module obtains the attribute information of all plugins through the plugin reader, and when the attribute information reading fails, it creates an independent verification instance to run the plugin corresponding to the failed reading and obtains the attribute information of the corresponding plugin based on the running result.

4. The online code development system according to claim 2, characterized in that, The plugin management module monitors the online IDE instances running in the first and second underlying editing environments respectively through a first probe, in order to read the attribute information of all plugins, identify plugins that have taken effect, and monitor plugin update and plugin addition actions.

5. The online code development system according to claim 1, characterized in that, The plugin management module monitors plugin update and plugin addition actions through a created plugin loader. It responds to the plugin update action to update the active plugins based on the association, and responds to the plugin addition action to add plugins based on the association. Furthermore, after the first online IDE or the second online IDE restarts, the plugin loader reloads the active plugins on the first online IDE or the second online IDE according to the monitoring results.

6. An online code development system according to any one of claims 1-5, characterized in that, The online code development system further includes a configuration management module, which manages the first configuration information of the first online IDE and the second configuration information of the second online IDE. The first configuration information enables the first online IDE to perform online editing of the first code, and the second configuration information enables the second online IDE to perform online editing of the second code.

7. The online code development system according to claim 6, characterized in that, The configuration management module monitors the online IDE instances running in the first and / or second underlying editing environments respectively using a second probe to determine at least one of the following: the first configuration information of the first online IDE, the second configuration information of the second online IDE, whether the first online IDE has restarted, whether the second online IDE has restarted, and whether the second probe is adapted to at least one of the first and / or second underlying editing environments and their versions.

8. A loader module, characterized in that, The loader module is connected to a first online IDE that performs first online code editing and has a first underlying editing environment, and a second online IDE that performs second online code editing and has a second underlying editing environment, so as to have an association with all plugins available in the first and second underlying editing environments, and manage plugins accordingly in at least one of the following ways: Monitor the first underlying editing environment of the first online IDE and the second underlying editing environment of the second online IDE to identify the plugins that have taken effect; Monitor plugin update actions and plugin addition actions. When a plugin update action is detected, update the active plugins based on the association relationship. When a plugin addition action is detected, add the plugin based on the association relationship. The first underlying editing environment is different from the second underlying editing environment.

9. A computer storage medium, characterized in that, The computer storage medium stores a computer-executable program. When the computer-executable program is run, it implements a set plugin management logic, which associates the plugin management module with all available plugins in the first and second underlying editing environments to manage and edit plugins in the following manner: The system monitors the first and second underlying editing environments to identify active plugins, monitors plugin update actions and plugin addition actions, responds to the plugin update actions to update active plugins based on the association, and responds to the plugin addition actions to add plugins based on the association. The system includes a first online IDE, a second online IDE, and a plugin management module. The first online IDE is used for online editing of the first code and has a first underlying editing environment for online editing of the first code. The second online IDE has a second underlying editing environment for online editing of the second code, and the first underlying editing environment is different from the second underlying editing environment.

Images