Online code development system, loader module and related products

Abstract

The invention provides an online code development system, a loader module and a related product, the online code development system is characterized in that a first online I DE is used for online editing of a first code, the first online I DE is provided with a first underlying editing environment for online editing of the first code, a second online I DE is used for online editing of a second code, and the second underlying editing environment is provided with a second underlying editing environment for online editing of the second code. The second online I DE is provided with a second underlying editing environment for online editing of a second code; the plug-in management module has an association relationship with all plug-ins available in the first bottom-layer editing environment and the second bottom-layer editing environment so as to manage the plug-ins according to at least one of the following modes: monitoring the first bottom-layer editing environment and the second bottom-layer editing environment, and determining the effective plug-ins; and monitoring a plug-in updating action and a plug-in adding action, responding to the plug-in updating action so as to update the effective plug-in based on the association relationship, and responding to the plug-in adding action so as to add the plug-in based on the association relationship.

Description

Technical Field

[0001] The present invention belongs to the field of data processing, and in particular relates to an online code development system, a loader module and related products. Background Art

[0002] An online integrated development environment (IDE) is a tool that allows developers to develop software directly 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 to perform programming work.

[0003] Currently, most online IDEs are built on underlying technologies such as Visual Studio Code (VSCode) or IntelliJIDEA, and only support plug-ins that are compatible with these underlying technologies. In addition, existing online IDEs usually only provide basic preset configurations, and users can customize them based on these configurations.

[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 adapt and install plug-ins. 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 online IDE instances is closely related to the life cycle of container instances. In order to optimize the use of server resources, inactive online IDE instances will be released. Since each instance manages its configuration file independently, the release of the instance will cause the online IDE configuration to be reset. Summary of the invention

[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 above-mentioned prior art.

[0006] An embodiment of the present application provides an online code development system, which includes 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 to 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 to manage the plug-ins in at least one of the following ways: monitoring the first underlying editing environment and the second underlying editing environment, determining plug-ins that have taken effect, monitoring plug-in update actions and plug-in addition actions, responding to the plug-in update action to update the plug-in that has taken effect based on the association relationship, and responding to the plug-in addition action to add a plug-in based on the association relationship.

[0007] The embodiment of the present application further provides a plug-in management module, which is connected to a first online IDE that performs online editing of a first code and has a first underlying editing environment, and a second online IDE that performs online editing of a second code and has 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 accordingly manages the plug-ins in at least one of the following ways:

[0008] Monitoring a first bottom-level editing environment of the first online IDE and a second bottom-level editing environment of the second online IDE to determine a plug-in that has taken effect;

[0009] Monitor plug-in update actions and plug-in addition actions. When a plug-in update action is detected, update the effective plug-in based on the association relationship; when a plug-in addition action is detected, add the plug-in based on the association relationship. The first underlying editing environment is different from the second underlying editing environment.

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

[0011] Monitor the first underlying editing environment and the second underlying editing environment, determine the plug-in that has taken effect, monitor the plug-in update action and the plug-in addition action, respond to the plug-in update action to update the plug-in that has taken effect based on the association relationship, and respond to the plug-in addition action to add a plug-in based on the association relationship;

[0012] Among them, there are a first online IDE, a second online IDE, and a 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. 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 benefits:

[0014] (1) By setting up a first online IDE (with a first underlying editing environment) and a second online IDE (with a second underlying editing environment), it is possible to meet the needs of different developers for different underlying editing environments, such as corresponding to different IDE technology stacks commonly used by front-end and back-end developers. In addition, the plug-in management module is associated with all plug-ins available in these two different underlying editing environments, and can monitor different underlying editing environments, determine plug-ins that have taken effect, and respond to plug-in update actions and add actions. This makes it possible to effectively manage plug-ins when facing different underlying editing environments, solving the problem of difficulty in unified support and plug-in adaptation and installation due to different IDE technology stacks.

[0015] (2) In this application, since the plug-in management module has a specific association with all plug-ins in different underlying editing environments, it manages plug-ins from the overall system level, rather than relying on a single online IDE instance to manage plug-in related configurations. Even if an online IDE instance is released due to inactivity or other reasons, the plug-in management module can still accurately update and add plug-ins based on its association with the plug-in when other related online IDE instances (such as the first online IDE or the second online IDE) need it, maintain the consistency of plug-in related configurations, and avoid the configuration reset problem 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 with different underlying editing environments, and the plug-in management module that cooperates therewith, it is possible to meet the needs of different development roles such as the front-end and the back-end for different IDE technology stacks, so that various developers can choose the appropriate underlying editing environment for code development according to their own habits and project requirements in a unified online code development system, and can conveniently manage plug-ins, which greatly improves the flexibility of development and compatibility with different development scenarios. In addition, with the help of the plug-in management module, plug-ins are uniformly managed from the system level, avoiding the waste of resources that may occur when each online IDE instance manages the plug-in configuration separately (such as repeated storage of similar plug-in configurations, etc.), and achieving more efficient resource utilization. On the other hand, it solves the problem of configuration reset caused by the release of the online IDE instance, making the system configuration more stable, reducing the extra workload caused by configuration loss or reset during the development process, and further optimizing the configuration management of the entire online code development system.

[0017] Furthermore, the plug-in management module can monitor plug-in update and addition actions, and respond in a timely manner based on its association with all plug-ins, whether for plug-ins in the first underlying editing environment or the second underlying editing environment. This allows plug-in maintenance and updates to be carried out in an orderly manner under a unified management mechanism, and developers do not need to worry about untimely plug-in updates or compatibility issues due to differences in different underlying editing environments, which improves the convenience and reliability of plug-in maintenance and updates. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, it is possible to obtain other drawings based on these drawings without paying creative labor.

[0019] Figure 1 This is a structural diagram of an online code development system according to an embodiment of the present application.

[0020] Figure 2 This is a structural diagram of a loader module according to an embodiment of the present application.

[0021] Figure 3 This is a structural diagram of a loader module according to an embodiment of the present application. DETAILED DESCRIPTION

[0022] The implementation of any technical solution of the embodiments of the present application does not necessarily require achieving all of the above advantages at the same time.

[0023] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work 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 the present application. Figure 1 As shown, it includes 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 to the first online IDE and the second online IDE, the plug-in management module has an association relationship with all plug-ins available under the first underlying editing environment and the second underlying editing environment to manage plug-ins in at least one of the following ways: monitoring the first underlying editing environment and the second underlying editing environment, determining plug-ins that have taken effect, monitoring plug-in update actions and plug-in addition actions, responding to the plug-in update action to update the plug-in that has taken effect based on the association relationship, and responding to the plug-in addition action to add a plug-in based on the association relationship.

[0025] For this reason, the online code development system of the present application, by setting the first online IDE and the second online IDE with different underlying editing environments, and the plug-in management module closely associated therewith, brings many significant technical benefits. On the one hand, it can well adapt to the needs of different developers such as the front-end and the back-end 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 difficult unified support and plug-in adaptation and installation difficulties caused by different technology stacks, and greatly improve the development flexibility and compatibility with different scenarios. On the other hand, the plug-in management module uniformly manages plug-ins from the system level, avoids the waste of resources generated by each online IDE instance managing the plug-in configuration separately, realizes efficient resource utilization, and solves the problem of configuration reset caused by the release of the online IDE instance, making the system configuration more stable, reducing the extra workload caused by configuration-related problems in the development process, and optimizing configuration management. In addition, the plug-in management module can timely monitor and respond to the update and increase of plug-ins under different underlying editing environments, so that plug-in maintenance and update are carried out in an orderly manner under a unified mechanism, and the convenience and reliability of plug-in maintenance and update are improved.

[0026] Optionally, the plug-in management module is also used to read the attribute information of all the plug-ins to maintain all the plug-ins, and the attribute information includes: basic information of the plug-in, the version of the plug-in, the applicable environment of the plug-in, and the environment-applicable version of the plug-in; if the attribute information fails to be read, an independent verification instance will be created to load the plug-in corresponding to the failure to read the attribute information onto the independent verification instance for execution, and based on the result of the execution, the attribute information of the corresponding plug-in will be obtained.

[0027] Therefore, the plug-in management module has the following technical benefits:

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

[0029] By reading various attribute information of the plug-in, including basic information, version, applicable environment, and applicable version of the environment, the plug-in management module can fully and deeply understand the specific situation of each plug-in. This makes the maintenance of the plug-in more accurate and targeted. For example, according to the version information of the plug-in, it can be known in time whether it needs to be updated. According to the applicable environment and applicable version information of the environment, it can ensure that the plug-in runs correctly in the appropriate underlying editing environment, thereby effectively avoiding failures caused by problems such as mismatch between the plug-in and the environment, and ensuring the stable operation of the entire online code development system.

[0030] 2. Troubleshooting and Adaptation Optimization

[0031] When the attribute information fails to be read, a mechanism is created to create an independent verification instance and run the corresponding plug-in on it to obtain the attribute information, which provides an effective way to resolve possible plug-in anomalies. On the one hand, this helps to quickly locate whether there is a problem with the plug-in itself that causes the attribute information to not be read normally, or other reasons such as compatibility conflicts with the current system environment. On the other hand, after running the plug-in on an independent verification instance to obtain accurate attribute information, the plug-in can be further adjusted or optimized in a targeted manner to better adapt to the 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] 3. Improve the overall stability of the system

[0033] With the help of careful control of plug-in attribute information and effective means of handling failures in reading attribute information, the stability of the entire online code development system has been significantly improved. Because the plug-in is an important part of the system, whether it can operate normally and whether it is compatible with the system environment are directly related to the operating status of the system. Through the above functions of the plug-in management module, potential plug-in-related problems can be discovered and solved in a timely manner, reducing the risks of system crashes and functional abnormalities caused by plug-in failures or mismatches, ensuring that the system can continue to provide services to developers in a stable manner.

[0034] 4. Easy for developers to manage

[0035] For developers, the plug-in management module can clearly present the attribute information of the plug-in, so that they can more intuitively understand the function, scope of application, version status, etc. of each plug-in. When it is necessary to update, replace or troubleshoot a plug-in, developers can make reasonable decisions based on this accurate attribute information, which greatly improves the convenience and effectiveness of developers' plug-in management, thereby improving the efficiency of the entire development work.

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

[0037] For reading plug-in attribute information, 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 plug-in's internal data structure or configuration file. For example, for the basic information of a plug-in, the plug-in name, author, description, etc. may be obtained by reading specific fields in the plug-in metadata file; for version information, the accurate version number can be obtained from the plug-in version identification file or a specific version record area.

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

[0039] Regarding data parsing and organization, once the original plug-in attribute information data is obtained through the interface, the plug-in management module will perform data parsing operations. For data in different formats (such as text format, binary format, etc.), the corresponding parsing algorithm will be used to convert it into a structured data form that can be processed and understood. The parsed attribute information will be organized according to the established classification method. For example, basic information, version information, applicable environment information, and environment applicable version information will be stored in different memory areas or data structures for subsequent query, analysis, and maintenance operations.

[0040] In order to handle the failure of reading attribute information, when trying to read the plug-in attribute information, the plug-in management module will set up a corresponding detection mechanism to determine whether the reading fails. This may include checking whether the acquired data is complete, whether it meets the expected format requirements, whether there is data missing or error, etc. For example, if the plug-in version information read is not in a valid version number format (such as missing numbers, illegal characters, etc.), or the applicable environment information is empty (indicating that the plug-in adapted environment cannot be determined), it is determined that the attribute information reading failed.

[0041] For independent verification instance creation, when a failure to read attribute information is detected, the plug-in management module will call system resources to create an independent verification instance. This independent verification instance is an isolated space that is relatively independent of the normal operating environment. It can be an independent operating environment based on virtual machine technology, container technology, etc. Its purpose is to prevent plug-ins that fail to read attribute information from interfering with normal system operations. When creating an independent verification instance, memory, CPU and other resources will be reasonably allocated to the instance based on the system's resource status and configuration requirements to ensure that it has sufficient operating capacity to load and run plug-ins.

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

[0043] Once the plug-in is loaded, it is started in the independent verification instance. During the operation, the independent verification instance monitors the running status of the plug-in, recording information such as the plug-in startup time, memory usage during operation, and whether there are any abnormal errors.

[0044] For the attribute information acquisition from running results, the attribute information of the plug-in is obtained according to the result of running the plug-in in the independent verification instance. For example, if the plug-in successfully connects to a certain underlying editing environment during operation and displays the adapted environment prompt information, then its applicable environment and environment applicable version information can be determined; if the plug-in displays its own version identification or related version prompts during operation, then its accurate version information can be obtained. For the basic information of the plug-in, it may be necessary to comprehensively analyze and extract from the user interface, log records, etc. displayed when the plug-in runs in the independent verification instance, such as obtaining the plug-in name from the plug-in startup interface, and obtaining the plug-in author and other information from the log. The obtained attribute information will be verified and sorted again to ensure its accuracy and completeness, and then updated to the attribute information storage area of ​​the plug-in management module to facilitate subsequent normal maintenance operations on the plug-in.

[0045] Optionally, the plug-in management module is further configured to reload the plug-in that has taken effect on 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.

[0046] When the plug-in management module has the function of reloading the effective plug-in according to the monitoring result after the first online IDE or the second online IDE is restarted, there are multiple technical benefits as follows:

[0047] 1. Maintaining consistency in the development environment

[0048] 1. During the online IDE restart process, if there is no mechanism to reload the effective plug-in, the status of the plug-in will not be automatically restored after the restart, and the developer may need to manually reconfigure and enable each plug-in, which is not only cumbersome but also prone to omissions or configuration errors. The automatic reloading function of the plug-in management module can ensure that the effective status of the plug-in can be continued before and after the restart, so that when the developer enters the development environment again, the plug-in they rely on can be in the previous normal working state, maintaining the consistency of the development environment.

[0049] 2. You may need to frequently restart the online IDE at different stages of development, such as when debugging code or switching projects. If each restart causes the plugin status to change, the development environment will be different after each restart, which is extremely disadvantageous for developers who need to accurately reproduce problems and continue development work. This function effectively avoids such environmental differences caused by restarts, ensuring that development work can be carried out in a relatively stable and consistent environment.

[0050] 2. Improve development efficiency

[0051] 1. Developers do not need to spend extra time to recall and reconfigure the plug-ins that have taken effect before the restart. The plug-in management module will automatically complete the reloading operation based on the monitoring results, which greatly saves developers' time investment in plug-in configuration and enables them to focus more on code development itself.

[0052] 2. If the plug-in is not reloaded in time, some functions in the development process may not work properly. For example, if the code formatting plug-in is not loaded, it will affect the standard presentation of the code, and if the debugging plug-in is not loaded, it will hinder the smooth progress of debugging. By reloading the effective plug-in in time, such problems caused by the lack of plug-ins can be effectively avoided, ensuring that the development work can be carried out efficiently and smoothly.

[0053] 3. Enhance system stability

[0054] 1.: During the process of reloading the effective plug-in after restart, the plug-in management module operates based on the monitoring results. This means that it will ensure that the reloaded plug-in remains compatible with the online IDE after restart, avoiding system instability or abnormal operation of the plug-in due to compatibility issues, and further enhancing the stability of the entire online code development system.

[0055] 2. This function makes the loading of plug-ins follow a standardized process in the special case of online IDE restart, that is, accurately reload the effective plug-ins according to the monitoring results. This standardized operation helps reduce the risk of system failure caused by improper plug-in loading and improves the overall reliability of the system.

[0056] To this end, in a specific application scenario, implementing the plug-in management module to reload the effective plug-in according to the monitoring result after the first online IDE or the second online IDE is restarted may include the following technical processing procedures:

[0057] For the monitoring and data recording stage, during the normal operation of the first online IDE and the second online IDE, the plug-in management module will continue to comprehensively monitor the plug-ins running on these two IDEs. The monitoring content includes the running status of the plug-in (such as whether it is running, whether an error occurs, etc.), the interaction between the plug-in and the IDE (for example, whether the instructions issued by the IDE are received and processed normally), and the resource usage of the plug-in (such as memory, CPU usage, etc.). By embedding a specific monitoring code segment in the plug-in code or using the plug-in monitoring interface provided by the IDE, the plug-in management module can obtain information related to these plug-ins in real time 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 plug-ins, the plug-in management module will clearly identify which plug-ins are effective on the first online IDE and the second online IDE. The basis for judging whether the plug-in is effective may include whether the plug-in is successfully started, whether the necessary initialization process is completed and whether it can normally respond to the relevant operations of the IDE.

[0059] For the effective plug-ins, the plug-in management module will record the relevant information in detail, such as the plug-in's unique identifier (which can be a unique code generated by combining the plug-in name, version number, author and other information), the plug-in's installation path in the IDE, and the information of other components or libraries that the plug-in depends on, etc. These records will also be stored in the monitoring data storage area to provide an accurate data basis for subsequent reloading operations.

[0060] In the IDE restart detection and response phase, the plug-in management module will interact with the underlying systems of the first online IDE and the second online IDE to monitor the running status of the two IDEs in real time. When a restart event is detected in the first online IDE or the second online IDE (for example, a restart notification signal is received from the IDE, or the restart process is found to be in progress by regularly checking the process status of the IDE), the plug-in management module will immediately start the plug-in reloading process for this restart.

[0061] After learning that the IDE has been restarted, the plugin management module will first read all the information about the plugins that have been effective on the restarted IDE from the monitoring data storage area. This includes obtaining the unique identifier, installation path, and dependent component information of the effective plugin, so as to accurately find the plugin that needs to be reloaded and make full preparations for the subsequent reloading operation.

[0062] During the plug-in reloading phase, the plug-in management module will accurately find the corresponding plug-in resources in the local storage system or remote server (if the plug-in resources are stored remotely) based on the installation path and unique identifier of the effective plug-in. This may involve traversing the file system directory, querying database records, etc. to ensure that the complete plug-in file and related resources (such as plug-in configuration files, dependent library files, etc.) can be obtained.

[0063] Before reloading the plug-in, the plug-in management module will check the compatibility of the plug-in with the restarted online IDE again. This may include comparing the minimum IDE version required by the plug-in with the actual version of the IDE after the restart, and checking whether the components or libraries that the plug-in depends on are still available in the restarted IDE environment. If a compatibility issue is found, the plug-in management module may take corresponding remedial measures, such as trying to update the plug-in version, installing missing components or libraries, etc., to ensure that the plug-in 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 reload the plug-in into the restarted first online IDE or second online IDE according to the plug-in loading specification of the IDE. This may involve calling the IDE's plug-in loading function, passing relevant parameters (such as the plug-in installation path, configuration file path, etc.), etc., to ensure that the plug-in can be started and run correctly.

[0065] During the reloading process, the plug-in management module will also monitor the plug-in reloading status in real time, such as whether it is successfully started, whether an error occurs, etc., and promptly feedback this information to the developer (through the IDE message prompt box, log records, etc.) so that the developer can promptly understand the progress of the plug-in reloading.

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

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

[0068] 1. Comprehensive and accurate plugin description

[0069] 1. Through the plugin reader, the attribute information of all plugins can be read to obtain the basic information, version, applicable environment, applicable version of the environment, etc. This allows the plugin management module to fully and deeply understand the specific characteristics and requirements of each plugin, so as to make more accurate decisions in plugin management, maintenance, and adaptation with online IDE.

[0070] 2. Understanding the applicable environment and applicable version of the plug-in will help 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), ensuring that the plug-in performs best in the matching underlying editing environment and avoiding problems such as abnormal plug-in operation or limited functions due to environment mismatch.

[0071] 2. Effectively deal with attribute reading failure

[0072] 1. When the attribute information fails to be read, a mechanism is created to create an independent verification instance and run the corresponding plug-in to obtain the attribute information, which provides an effective way to troubleshoot possible faults in the plug-in itself. By running the plug-in in an independent verification instance, you can observe the actual running performance of the plug-in and determine whether the attribute information cannot be read normally due to problems with the plug-in's own code, damaged configuration files, or compatibility conflicts with the system environment, and then take targeted repair measures.

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

[0074] 3. Improve the overall stability of the system

[0075] 1. Accurately grasping the plug-in attribute information and being able to properly handle the failure to read the attribute information will 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 the system to crash or unpredictable errors. The above mechanism can effectively avoid such situations and ensure the stable operation of the system.

[0076] 2. This standardized way of obtaining plug-in attribute information, including the handling of attribute information reading failure, optimizes the workflow of the plug-in management module. It enables the plug-in management module to operate in an orderly manner when facing various plug-in situations, thereby improving the efficiency and reliability of plug-in management in the entire online code development system, and further enhancing the overall stability of the system.

[0077] 4. Easy for developers to manage

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

[0079] 2. Developers do not need to spend a lot of energy to troubleshoot the reasons for the failure of attribute information reading and obtain relevant attribute information. The plug-in management module has completed these tasks through its own mechanism. This greatly simplifies the plug-in management work of developers, allowing them to focus more on core businesses such as code development, improving development efficiency.

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

[0081] In order to obtain plug-in attribute information through the plug-in reader, a special plug-in reader component is built inside the plug-in management module. During the initialization phase, the plug-in reader will connect with the system's plug-in management framework to obtain relevant information such as the basic storage location and access rights of all available plug-ins, so that the attribute information of each plug-in can be accurately found and read later.

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

[0083] For each plug-in that needs to read property 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 call mechanisms to interact with the plug-in based on the type of plug-in (such as a plug-in developed based on a specific 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 read requests to the plug-in and wait for the plug-in's response, thereby starting the process of obtaining attribute information.

[0085] After the connection with the plug-in is established, the plug-in reader will read the attribute information of the plug-in in sequence according to the pre-defined attribute information acquisition process.

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

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

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

[0089] During the reading process, the plug-in reader will temporarily store the acquired attribute information (such as in a local cache or memory data structure) for subsequent sorting and verification.

[0090] Once the plug-in attribute information is read, the plug-in reader will organize the acquired information and classify different types of attribute information according to the established classification method (such as 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 will verify the collated attribute information. The verification content includes the integrity of the information (whether all the expected attribute information has been obtained), the correctness of the format (such as whether the version number conforms to the standard format, whether the description of the applicable environment is clear and accurate, etc.), and if any problems are found, appropriate remedial measures will be taken in a timely manner (such as re-reading, error prompts, etc.) to ensure that the attribute information finally obtained is accurate and reliable.

[0092] In order to handle the failure of attribute information reading, a complete failure detection mechanism will be set up to determine whether the attribute information reading failure occurs during the process of the plug-in reader reading the plug-in attribute information.

[0093] The basis for detection mainly includes whether a complete response from the plug-in is not received within the specified time (that is, after the read request is issued, all expected attribute information is still not obtained after a certain period of time), whether the obtained information has obvious format errors (such as unrecognizable version number format, confusing applicable environment description, etc.), whether there is any missing information (such as some key attribute information is not obtained), etc.

[0094] When any of the above situations occurs, it is determined that the attribute information reading has failed.

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

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

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

[0098] Load the plug-in corresponding to the failure to read the attribute information into the created independent verification instance. This involves interacting with the runtime environment of the independent verification instance, and accurately deploying the plug-in code and related resources to the instance according to the plug-in loading specifications and requirements. For example, if the plug-in is developed based on a specific programming language, then it is necessary to load the plug-in's executable file, dependent library files, etc. into the corresponding locations in the container in sequence according to the loading mechanism of the language in the container environment. Once the plug-in is loaded, start the plug-in in the independent verification instance. During the operation, the independent verification instance will monitor the running status of the plug-in, recording conditions such as the startup time of the plug-in, memory usage during operation, and whether abnormal errors occur.

[0099] The attribute information of the plug-in is obtained based on the result of the plug-in running in the independent verification instance. For the basic information of the plug-in, it may be necessary to comprehensively analyze and extract from the user interface, log records, etc. displayed when the plug-in runs in the independent verification instance, such as obtaining the plug-in name from the plug-in startup interface and obtaining the plug-in author and other information from the log. For the version information of the plug-in, if the plug-in displays its own version identification or related version prompts during operation, then its accurate version number can be obtained. Regarding the applicable environment and applicable version of the environment of the plug-in, if the plug-in successfully connects to a certain underlying editing environment during operation and displays the adapted environment prompt information, then its applicable environment and applicable version information of the environment can be determined. The obtained attribute results will be verified and sorted again to ensure their accuracy and completeness, and then updated to the attribute information storage area of ​​the plug-in management module to facilitate subsequent normal maintenance operations on 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 created first probe, so as to read the property information of all the plug-ins, determine the plug-ins that have taken effect, and monitor plug-in update actions and plug-in addition actions.

[0101] To this end, the plug-in management module monitors the relevant online IDE instances by creating a first probe, which has the following technical benefits:

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

[0103] 1. The first probe monitors the online IDE instances running in different underlying editing environments (first underlying editing environment, second underlying editing environment), and can read the attribute information of all plug-ins. This includes the basic information, version, applicable environment, applicable version of the environment, etc. of the plug-in, so that the plug-in management module can fully and deeply understand the specific characteristics and status of each plug-in, providing a detailed basis for subsequent plug-in management, maintenance, and adaptation with the online IDE.

[0104] 2. With the help of the probe's monitoring function, it is possible to accurately determine which plug-ins are in effect in each online IDE instance. This helps the plug-in management module to identify the plug-ins that are actually in effect in the current development environment, so that plug-in related operations (such as updates, maintenance, etc.) can be more targeted, avoiding unnecessary operations on ineffective plug-ins, and improving the accuracy of plug-in management.

[0105] 2. Efficient and real-time dynamic monitoring of plug-ins

[0106] 1. The first probe can monitor the plug-in update action in real time. Once a plug-in releases a new version and there is an update requirement in the online IDE instance, the plug-in management module can be informed of this situation in the first place. This allows the plug-in to be updated in a timely manner, ensuring that its functions are always kept up to date and compatibility with the online IDE can be maintained, which is conducive to developers using the latest plug-in functions to carry out work and improve development efficiency.

[0107] 2. Similarly, the probe can quickly detect the addition of plug-ins. When developers need to add new plug-ins to a specific online IDE instance, the plug-in management module can obtain this information through the probe and perform corresponding processing in a timely manner, such as checking the compatibility of the new plug-in with the underlying editing environment and other effective plug-ins, etc., to ensure that the new plug-in can be added smoothly and run normally, providing developers with a more convenient way to expand plug-ins.

[0108] 3. Improve the overall stability and compatibility of the system

[0109] 1. Through continuous monitoring of online IDE instances in different underlying editing environments, the plug-in management module can better grasp the compatibility between plug-ins and online IDEs. For possible plug-in and IDE incompatibility issues, it can be discovered in advance and measures can be taken to adjust them, such as prompting developers to update plug-in versions or replace appropriate plug-ins, thereby avoiding system crashes, functional abnormalities, and other problems caused by plug-in and IDE incompatibility, and enhancing the overall stability of the system.

[0110] 2. Based on the plug-in information obtained by probe monitoring and the grasp of plug-in dynamics, the plug-in management module can perform plug-in configuration management more reasonably. For example, according to the applicable environment and effective status 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 the appropriate plug-in configuration, thereby improving the system's compatibility and overall operating efficiency.

[0111] 4. Make it easier for developers to manage plugins

[0112] 1. For developers, the plug-in management module provides a clear plug-in status view through plug-in related information presented by probe monitoring, such as effective plug-ins, plug-in update status, etc. Developers can intuitively understand the running status of each plug-in in the system, which is convenient for them to select, update or delete plug-ins when needed, improving the convenience of developers to manage plug-ins.

[0113] 2. Since the plug-in management module can monitor and handle various dynamic situations of plug-ins in a timely manner, developers do not need to spend a lot of energy to check whether the plug-in needs to be updated, whether it is compatible with the environment, etc. This greatly reduces the burden of developers in plug-in management, allowing them to focus more on core businesses such as code development, improving development efficiency.

[0114] In a specific application scenario, 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 created first probe, thereby realizing functions such as reading the attribute information of all plug-ins, determining the effective plug-ins, monitoring the plug-in update action, and monitoring the plug-in addition action. The technical implementation process may include the following technical processing:

[0115] For the creation and initialization of the probe, according to the monitoring goal of the online IDE instance to be achieved, it is clear that the first probe needs to have the functions of reading all plug-in attribute information, determining the effective plug-ins, monitoring plug-in update actions, and 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 those developed based on a specific programming language or platform) and the underlying editing environment, select a suitable technical framework 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 it involves an online IDE related to Web applications, a framework suitable for Web monitoring may be selected (such as Prometheus combined with related Web client libraries to monitor various indicators of Web services, which can be expanded here to monitor plug-in related information).

[0117] After the probe is created, initialization settings are performed, which include configuring the connection parameters between the probe and the first online IDE and the second online IDE, such as specifying the network address, port number, and authentication information (if necessary) of the IDE instance, so that the probe can successfully establish a communication connection with the target IDE instance.

[0118] At the same time, set the monitoring frequency of the probe, that is, how often to conduct a comprehensive monitoring of the online IDE instance. This frequency needs to be determined based on factors such as system performance, the expected frequency of plug-in updates, and the requirements for real-time performance. 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 can be appropriately extended (such as monitoring every 30 minutes).

[0119] In order to establish a connection with the online IDE instance, the first probe needs to perform corresponding protocol adaptation according to the network communication protocol (such as HTTP, HTTPS, RPC, etc.) adopted by the online IDE instance. If it is HTTP / HTTPS protocol, the probe may need to send a monitoring request to the IDE instance by constructing a suitable HTTP request header, request body, etc., and process the response from the IDE instance. For the RPC protocol, the probe needs to follow the corresponding RPC call specification and perform remote procedure call interaction with the IDE instance.

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

[0121] To read the plug-in attribute information, once the connection is established with the online IDE instance, the first probe first needs to identify the storage structure of the plug-in in each underlying editing environment (first underlying editing environment, second underlying editing platform). Different IDEs and underlying editing environments may have different plug-in storage methods. For example, some may store the plug-in in a specific directory as a file, 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 basic information of the plug-in, such as the plug-in name, author, description, etc., the probe may read it from the plug-in metadata file (such as the manifest file). It extracts the corresponding information in a predefined format by parsing specific fields in the file. For example, if the manifest file is in JSON format, the probe will use the 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 a version identification area specially set up by the plug-in, such as a version number file or a specific constant in the plug-in code. The probe will extract the accurate version number by identifying and accessing these areas. For example, in some IDEs, the plug-in version number may be stored in a file called version.txt. The probe will read the content of the file and parse the version number.

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

[0125] To determine the effective plug-in, the first probe will continuously monitor the running status of the plug-in in the online IDE instance. It determines whether the plug-in is effective by observing indicators such as whether the plug-in is running, whether error messages appear, and whether the necessary initialization process has been completed. For example, if the plug-in has been started and no error prompts appear, and it can respond normally to relevant instructions issued by the IDE instance, then it can be preliminarily determined that the plug-in is effective.

[0126] In addition to monitoring the running status of the plug-in itself, the probe also checks the interaction between the plug-in and the online IDE instance. If the plug-in can normally receive and process the instructions issued by the IDE instance, and can correctly feed back the processing results to the IDE instance, then this is also an important basis for judging whether the plug-in is effective. By comprehensively considering the running status of the plug-in and the interaction with the IDE, the probe can more accurately determine the effective plug-in.

[0127] To monitor plugin updates, the first probe will periodically check the plugin versions in the online IDE instance. It obtains the current version information of the plugin (such as the method for obtaining plugin version information described above) and compares it with the last monitored version information. If the version number is found to have changed, it can be determined 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 the plugin update comes from an official new version, a developer's own compiled update, or other channels. By understanding the source of the update, you can better evaluate the reliability and security of the update, providing a reference for subsequent update processing.

[0129] For monitoring plugin addition actions, when a new plugin is added to an online IDE instance, the first probe will track the installation directory of the new plugin. It discovers the installation location of the new plugin by monitoring file system changes (such as new files or directories) of the IDE instance. Once the installation directory of the new plugin is determined, the new plugin can be further monitored and processed.

[0130] After the new plug-in is installed, the probe will check the initialization of the new plug-in. It determines whether the new plug-in is successfully added and effective by observing whether the new plug-in has completed the necessary initialization process (such as loading dependent libraries, setting initial parameters, etc.) and whether it can respond normally to relevant instructions issued by the IDE instance. By monitoring the initialization of the new plug-in, problems that may arise during the addition of the new plug-in can be discovered and resolved in a timely manner.

[0131] In the specific implementation, in addition to reading plug-in attribute information, determining effective plug-ins, monitoring plug-in update actions, and plug-in addition actions based on the first probe, the following alternative means can also be used to achieve the same purpose:

[0132] 1. Extend the monitoring and management functions built into the IDE

[0133] Analysis of the existing monitoring mechanism of IDE:

[0134] Many mature online IDEs (such as Visual Studio Code, IntelliJ IDEA, etc.) have built-in monitoring mechanisms to monitor their own operating status, resource usage, etc. We can deeply analyze the implementation principles and data acquisition methods of these IDE built-in monitoring functions to see if they can be expanded on this basis to achieve monitoring of plug-in related information.

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

[0136] Expand IDE management interface:

[0137] IDEs also usually provide some management interfaces for external programs or plug-ins to interact with, in order to implement functions such as installing and uninstalling plug-ins. These management interfaces can be extended and developed to not only handle basic plug-in management operations, but also return plug-in property information, report whether the plug-in is effective, and notify external parties about plug-in updates and additional actions.

[0138] By adding corresponding functional logic based on the IDE management interface, for example, when the plug-in installation interface returns the installation result, it also returns the detailed attribute information of the plug-in (by reading the relevant configuration files or data structures of the plug-in during the installation process), and continuously obtains the running status of the plug-in through the interface during the subsequent operation to determine whether it is effective, and uses the interface to listen to plug-in updates and add actions.

[0139] 2. Use proxy server mode for monitoring

[0140] Set up a proxy server:

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

[0142] For example, when a plug-in needs to download an update from an external server, the proxy server can intercept the download request and analyze the plug-in version information, update source, etc. contained therein, thereby monitoring the plug-in update action. Similarly, when a plug-in interacts with other local components to obtain resources or perform initialization operations, the proxy server can understand the running status of the plug-in by analyzing these interaction requests, and then determine which plug-ins have taken effect.

[0143] Configure proxy rules and analysis logic:

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

[0145] For plug-ins that have been confirmed to be effective, the proxy server can determine whether the plug-in has completed the necessary initialization process and can normally respond to the instructions issued by the IDE instance based on the network traffic characteristics generated when the plug-in interacts with the IDE instance (such as frequent request response patterns, specific command interactions, etc.), thereby determining whether the plug-in is effective.

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

[0147] 3. Implementation based on log analysis

[0148] Collect relevant log files:

[0149] Online IDE instances and plug-ins usually generate various log files during operation, recording their own operation status, operation history, error information, etc. You can collect these log files related to online IDEs and plug-ins, including the main operation log of the IDE, plug-in-specific logs (if they are set separately), and process logs that may involve plug-in installation, update, etc.

[0150] For example, in some IDEs, the plug-in installation process will record detailed installation steps, problems encountered, and other information in a special installation log, and when the plug-in is running, it will record information such as startup time, running status, and interaction with the IDE in its own running log.

[0151] Parsing and analyzing log content:

[0152] The collected log files are parsed, and according to the formats of different log files (such as text format, XML format, etc.), corresponding parsing methods (such as regular expression parsing, XML parser, etc.) are used to convert their contents into analyzable structured data forms.

[0153] Then, by analyzing these structured data, we can monitor the plug-in related information. For reading plug-in attribute information, we can find records of plug-in name, author, description, version and other attributes from the plug-in installation log or operation log. Although it may not be as accurate as directly obtaining it, it can provide a general understanding.

[0154] For plug-ins that have been confirmed to be effective, by analyzing the plug-in startup, running status, interaction with the IDE and other records in the plug-in operation log, it is determined whether the plug-in has completed the necessary initialization process and can normally respond to the instructions issued by the IDE instance, thereby determining whether the plug-in is effective.

[0155] To monitor plugin update actions, find information about plugin version changes, update sources, etc. from the plugin update log (if there is a separate setting) or the IDE main run log to monitor plugin update actions.

[0156] For monitoring plug-in addition actions, analyze the installation process of the new plug-in from the new plug-in installation log, whether the necessary initialization process has been completed, and whether it can respond normally to the instructions issued by the IDE instance to determine whether it has been successfully added and taken effect.

[0157] Optionally, the plug-in management module monitors plug-in update actions and plug-in addition actions 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 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 plug-in loader.

[0158] To this end, the plug-in management module implements related functions through the created plug-in loader, which brings the following technical benefits to the online code development system in terms of plug-in management, development environment stability, development process optimization, and developer control over plug-ins:

[0159] 1. Efficient plug-in update and addition management

[0160] 1. The plugin loader can monitor plugin updates and update the plugins that have been in effect based on the association with each plugin. This ensures that plugins can keep up with new versions released by their developers in a timely manner, allowing developers to take advantage of the latest features and fixed vulnerabilities of plugins to improve development efficiency. For example, a code formatting plugin may provide more accurate formatting rules after being updated, and developers can enjoy these improvements immediately.

[0161] 2. The plugin loader provides a convenient way for developers to add new plugins by monitoring plugin addition actions and adding plugins based on associations. Developers do not need to go through a complicated manual configuration process. They only need to trigger the add action, and the plugin loader will automatically complete the relevant operations, ensuring that the new plugin can be properly integrated into the development environment and is compatible with existing plugins and online IDEs, reducing compatibility issues caused by improper plugin addition.

[0162] 2. Ensure 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-in according to the monitoring results. This allows the effective status of the plug-in before and after the restart to continue. When the developer enters the development environment again, the plug-in they rely on can be in the previous normal working state, maintaining the consistency of the development environment and avoiding the situation where the plug-in status is confused due to the restart and affects the development work.

[0164] 2. The plugin loader handles plugin updates, additions, and reloading after restart based on its association with the plugin and monitoring results. This means it ensures that the plugin is always compatible with the online IDE, avoiding system instability or plugin abnormal operation caused by compatibility issues, and further enhancing the stability of the entire online code development system.

[0165] 3. Optimize development process and resource utilization

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

[0167] 2. When updating, adding, and reloading plugins, the plugin loader will perform precise operations based on the associations and monitoring results, avoiding unnecessary resource waste, such as avoiding repeated downloads of existing plugin versions or loading incompatible plugins that occupy system resources but fail to work properly. By optimizing these plugin-related operations, more reasonable system resource utilization is achieved.

[0168] 4. Facilitate developers’ overall control of plug-ins

[0169] 1. The monitoring function of the plugin loader enables developers to clearly understand the status of plugin updates, additions, and reloading after IDE restart. This provides developers with a clear view of the plugin status, allowing them to get timely information about the plugin when needed and make reasonable decisions, such as deciding whether to further check the functions of a newly updated plugin.

[0170] 2. Through a series of plug-in management functions implemented by the plug-in loader, developers can more easily control the overall plug-in. They can use the plug-in loader to easily update, add or ensure the normal operation of the plug-in after restart according to project requirements, which improves the convenience and effectiveness of plug-in management, thereby improving the efficiency of the entire development work.

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

[0172] For the creation and initialization of the plug-in loader, the overall architecture of the plug-in loader is planned according to the monitoring plug-in update action, add action and corresponding update, add and reload plug-in after restart. It is clear that it needs to interact with online IDE (first online IDE and second online IDE), plug-in and related monitoring data storage to complete various tasks. For example, it is determined that the plug-in loader should have an interface compatible with different underlying editing environments so that the plug-in can be accurately operated in the corresponding online IDE; at the same time, the internal data structure is designed to store the plug-in association relationship, monitoring results and other information for subsequent processing.

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

[0174] For different operating system environments (such as Windows, Linux, etc.), you also need to consider the operating system-related features and APIs to ensure that the plug-in loader can run stably in the corresponding environment. For example, in a Linux environment, you may need to use the Linux file system operation API to handle operations such as storing and reading plug-in files.

[0175] After the plugin loader is created, initialization settings are performed. This includes establishing connections with the first online IDE and the second online IDE, and configuring connection parameters such as network address, port number, 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 storing the plugin association relationship is loaded and initialized, and the association relationship data of the pre-configured plugin and the available plugins in different underlying editing environments are imported into it, so as to prepare for the subsequent plugin operation based on the association relationship.

[0176] In order to monitor plugin update actions, the plugin loader sets up a special update monitoring mechanism through the interactive interface with the online IDE and plugins. This may include regularly sending version query requests to the plugin to inquire about the current version information of the plugin; or monitoring the network port where the plugin is located (if the plugin communicates through the network for update) to capture possible update-related network traffic characteristics, such as specific update notification packets. For example, for some plugins that are updated through the HTTP protocol, the plugin loader can regularly 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 a plug-in version change is detected, the plug-in loader must not only determine that there is an update action, but also identify the source of the update. It will analyze information such as update-related network traffic, file download sources (if the plug-in is updated by downloading files), and determine whether the update comes from an officially released new version, a developer's own compiled update, or other channels. At the same time, the source of the update is verified to ensure the legitimacy and security of the update. For example, for updates from official releases, verify whether their digital signatures are correct; for updates compiled by developers themselves, check whether they comply with the update process and permission requirements specified by the system, etc., to prevent malicious updates from causing system failures.

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

[0179] During the installation of a new plug-in, the plug-in loader will check the compatibility of the new plug-in with the online IDE and the plug-in that has been put into effect. It will compare and analyze the property information of the new plug-in (such as the applicable environment, dependent libraries, etc.) with the underlying editing environment of the online IDE and the relevant information of the plug-in that has been put into effect. For example, it will check whether the minimum IDE version required by the new plug-in matches the current online IDE version, whether the library that the new plug-in depends on already exists in the IDE environment and the versions are compatible, etc., to ensure that the new plug-in can be smoothly integrated into the existing development environment.

[0180] In response to the plug-in update action, the plug-in is updated. When it is determined that there is a plug-in update action and the verification is passed, the plug-in loader obtains the detailed information of the plug-in to be updated based on the stored plug-in 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 plug-in to be updated in different underlying editing environments is found, and it is determined whether the installation path of the plug-in in different IDEs and the interaction method with other plug-ins need to be adjusted after the update.

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

[0182] In response to the plug-in adding action, the plug-in adding action is performed. When the plug-in adding action is detected, the plug-in loader prepares the conditions for adding the new plug-in based on the plug-in association relationship. This includes checking whether the resources required by the new plug-in 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 plug-in in different underlying editing environments. For example, based on the association relationship of the new plug-in, determine the specific installation path of the new plug-in in the first online IDE or the second online IDE, and whether certain pre-components need to be installed first.

[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 new plugin's files to the specified installation path, setting initial parameters, starting the new plugin's initialization process, etc. For example, copy the new plugin's executable file from the download directory to the online IDE's plugin installation directory, then set the new plugin's startup parameters, start the new plugin's initialization process, and ensure that the new plugin can start and run normally.

[0184] In order to reload the effective plug-in after the IDE is restarted, the plug-in loader monitors the restart event of the first online IDE or the second online IDE through a continuous connection with the online IDE. It can be implemented in many ways, such as regularly checking the process status of the IDE, and when it is found that the process disappears and reappears and meets the restart characteristics, it is determined that the IDE is restarted; 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 situation.

[0185] After learning that the IDE has been restarted, the plugin loader immediately obtains detailed information about the plugins that were in effect on the IDE before the restart from the stored monitoring data, including the plugin's unique identifier, installation path, version number, interaction with other plugins, etc. This information was previously saved through monitoring and recording during the normal operation of the plugin, providing an accurate data basis for reloading the plugin.

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

[0187] Optionally, the online code development system also includes: a configuration management module, which is used 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 personalized editing needs, simplifying maintenance processes, ensuring system stability and compatibility, and facilitating version control and configuration migration:

[0189] 1. Personalization and code editing adaptation

[0190] 1. Provide specific first configuration information to the first online IDE so that it can efficiently perform online editing of the first code; provide corresponding second configuration information to 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.), ensuring that each online IDE can perform editing of the corresponding code in the most suitable configuration environment, thereby improving editing efficiency and accuracy.

[0191] 2. Developers can work in an online IDE configuration environment that they are familiar with and well-adapted to, based on the type of code they are responsible for (e.g., front-end developers for the first code, back-end developers for the second code). This kind of personalized customization helps developers edit code more comfortably and conveniently, reduces operational inconvenience and inefficiency caused by incompatible configurations, and improves the overall developer experience.

[0192] 2. Unified configuration management and convenient maintenance

[0193] 1. The configuration management module manages the first configuration information of the first online IDE and the second configuration information of the second online IDE in a unified manner. This avoids the management confusion that may be caused by the configuration information being scattered in various IDEs, and enables system administrators or related maintenance personnel to view, modify, and back up all important configuration information in a 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 control over the configuration information, maintenance personnel can quickly locate the specific configuration items that need 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] 3. 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 configuration information loss or errors due to unexpected situations (such as software updates, system failures, etc.), always keep the configuration of each online IDE in a correct and effective state, and maintain the overall stability of the system.

[0197] 2. Through the fine management of configuration information, the configuration management module can detect and solve possible configuration compatibility problems in advance. For example, ensure that the first configuration information is compatible with the underlying editing environment and related plug-in configurations on which the first online IDE is based, and perform similar processing on the second configuration information. This helps to avoid abnormal IDE operation and plug-in failure due to configuration incompatibility, and enhances the compatibility of online IDEs in different configuration scenarios.

[0198] 4. 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 the configuration versions at different stages can be recorded, which is convenient for tracing back to a specific configuration state when needed. For example, when a problem occurs, it can be quickly restored to the previous stable running configuration version, or during the development process, it can switch to the appropriate configuration version according to the project progress, which provides 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 in the new environment according to the original configuration requirements, reducing the trouble of resetting the configuration 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 to meet 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 a suitable storage method to save the first configuration information and the second configuration information. Common storage methods include databases (such as relational databases MySQL, PostgreSQL, etc., or non-relational databases such as MongoDB, etc.), configuration files (such as JSON format, XML format, etc.) or repositories based on version control systems (such as Git). For example, if database storage is selected, the corresponding database table structure will be designed according to the structure and characteristics of the configuration information, and different parts of the configuration information (such as editor settings, compiler options, debugger configuration, etc.) will be stored in different fields or tables for easy query, update and management. If a configuration file is used, the configuration information will be organized in an orderly manner according to certain format specifications (such as the key-value pair form of JSON) to facilitate reading and modification.

[0203] For the first configuration information and the second configuration information, the configuration management module will design a suitable data structure 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 compiler options, there may be another structure containing parameters such as target platform and optimization level. Similarly, a similar structure design will be performed for the configuration information of the second online IDE to accurately reflect the various configuration details it requires.

[0204] In order to facilitate management and distinction, the configuration management module will classify and identify 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 will be assigned a unique identifier so that it can be accurately located when querying, updating or referencing. For example, the "font size" configuration item in the editing configuration may be identified as "EDI TOR_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 will establish an interactive interface with the first online IDE and the second online IDE so as to acquire and set their configuration information. These interfaces can be implemented based on network communication protocols (such as HTTP, RPC, etc.), or interact using plug-in interfaces, APIs, etc. provided by the IDE itself. For example, if the first online IDE provides a RESTful 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 requests to acquire configuration information, PUT requests to update configuration information), and parse and process the returned results or send corresponding data according to the API specifications.

[0206] When it is necessary to obtain the first configuration information of the first online IDE or the second configuration information of the second online IDE, the configuration management module sends an acquisition request to the corresponding IDE through the above-mentioned interactive interface.

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

[0208] When it is necessary to set the first configuration information of the first online IDE or the second configuration information of the second online IDE, the configuration management module will first organize the configuration information to be set according to a predefined format (such as converting a structure or class instance into JSON or XML format, etc.) to make it conform to the format requirements acceptable to the IDE.

[0209] Then, the sorted 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 IDE's API for setting configuration information). After receiving the setting request, the IDE will apply the new configuration information to its own operating environment according to its own internal mechanism (such as updating local configuration files, records in the database, etc.), thereby completing the configuration information setting operation.

[0210] For the update and maintenance of configuration information, the configuration management module will continuously monitor whether there is a need to update the first configuration information or the second configuration information in the system. This can be achieved in a variety of ways, such as monitoring the configuration update request signal sent by the IDE itself (if the IDE has such a function), receiving manual update requests from developers or system administrators (through specific management interfaces or command line tools, etc.), or automatically determining whether certain configuration items need to be updated based on the progress and needs of the project. For example, when a developer finds that the code editing font size of the first online IDE needs to be adjusted to improve visibility during the development process, an update request will be sent to the configuration management module through a specific management interface, and the configuration management module will promptly monitor this need.

[0211] Once a configuration update requirement is detected, the configuration management module will operate according to the pre-established update process. First, the configuration information that needs 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 range of values, etc.). Then, according to the type of update requirement (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 relevant configuration item value will be modified, and the updated configuration information will be sent to the corresponding IDE for application through the interactive interface with the IDE; if it is an overall configuration update, all configuration information may be re-acquired, sorted and sent to the IDE to ensure that the new configuration can be fully and accurately applied to the IDE's operating environment.

[0212] The configuration management module will establish a backup and recovery mechanism for the configuration information. Before each update of the first configuration information or the second configuration information, the current configuration information will be backed up and stored in a specified backup location (such as another database table, backup file, etc.). When a problem occurs (such as abnormal operation of the IDE after the update, loss of configuration information, etc.), the previous configuration state can be quickly restored based on the backup information. For example, if an error is found in code editing after updating the configuration information of the first online IDE, the recovery mechanism can quickly return to the configuration before the update to avoid affecting the normal progress of development work.

[0213] The configuration management module for version control of configuration information will perform version control on the first configuration information and the second configuration information, and assign a unique version number to each configuration update. This version number can be a digital number (such as 1.0, 1.1, etc.) or other forms (such as timestamp + serial number, etc.) to facilitate identification and distinction of configuration status in different periods. At the same time, detailed information on each configuration update will be recorded, including update time, update content (such as which specific configuration items have been updated), update reasons (such as to adapt to new project requirements, fix a problem, etc.), etc., to form a configuration update log so that it can be reviewed back when needed.

[0214] When it is necessary to switch between different configuration versions, the configuration management module will obtain the configuration information of the corresponding version as required. If you are switching from the current version to a past version, the corresponding version information will be found from the backup storage location (such as a database table, backup file, etc.), and it will be reapplied to the corresponding IDE according to the above process of obtaining and setting the configuration information to restore it to the configuration state of that version. For example, if during the project development process it is found that the current configuration version has caused some problems and it is necessary to switch to the previous stable version, the configuration management module will find the information of that version by querying the configuration update log, and then reapply it to the first online IDE or the second online IDE to solve the problem and resume normal development.

[0215] Regarding the migration of configuration information, 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 the test environment) to another environment (such as the production environment), the configuration management module will first analyze the differences between the two environments, including differences in operating systems, network settings, resource configurations, etc. For example, the test environment may be run on a local development machine, while the production environment may be run on a cloud server. The configuration management module needs to analyze the differences between the two environments in terms of hardware, software, and network, so as to make corresponding adjustments during the migration process.

[0216] According to the results of the environmental difference analysis, the configuration management module will formulate a corresponding migration process. Generally speaking, the first configuration information and the second configuration information will be extracted from the storage method of the source environment (such as database, configuration file, etc.), and organized according to the requirements of the target environment (such as adjusting the configuration items related to network settings, modifying the compiler options according to the resource configuration, etc.). Then the organized configuration information is sent to the first online IDE and the second online IDE in the target environment according to the interaction method with the IDE in the target environment (such as through the new HTTP request format, adapting to the new API, etc.), so that it can operate normally 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 respectively through the created 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 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 their versions.

[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 understanding of IDE operation status, ensuring environment adaptation and compatibility, and facilitating operations for developers and administrators:

[0219] 1. 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 an accurate basis for subsequent configuration adjustment, update, and ensuring that the configuration matches the IDE operation requirements, and 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, plug-in installation or update, etc.). The continuous monitoring of the second probe can capture the dynamic changes of these configuration information in a timely manner, so that the configuration management module can make corresponding adjustments to ensure that the configuration always maintains the 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] 2. Real-time understanding of IDE running status

[0223] 1. Being able to monitor whether the first online IDE and the second online IDE are restarted is crucial for the configuration management module. Because IDE restart may affect the application and effectiveness of its configuration, by timely knowing the restart event, the configuration management module can quickly check whether the configuration is loaded correctly after the restart, whether additional configuration recovery or adjustment operations are required, etc., ensuring the consistency and effectiveness of the online IDE configuration before and after the restart, and maintaining the stability of the development environment.

[0224] 2. Understanding the restart status of the IDE and the real-time configuration information will help the system administrator or configuration management module to reasonably allocate system resources (such as memory, CPU, etc.) according to the actual operation status of the IDE. For example, if an online IDE restarts frequently and has high configuration requirements, it may be necessary to allocate more resources to it to ensure its stable operation, thereby improving the rationality and efficiency of system resource utilization.

[0225] 3. Ensure environmental 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 carried out accurately in the corresponding environment. It can effectively avoid monitoring failure or inaccuracy caused by incompatibility between the monitoring tool and the underlying editing environment, and ensure that the configuration management module can obtain real and reliable configuration information, operating status and other data about the online IDE, thereby enhancing the compatibility of the entire online code development system under different underlying editing environments and versions.

[0227] 2. By monitoring the online IDE instances in a specific underlying editing environment and version, the configuration management module can detect in advance possible compatibility issues between configuration and environment, plug-in and environment, etc. For example, if it is detected 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 developers to replace plug-ins, etc.) to solve the problem, avoiding system failures or development work obstructions caused by compatibility issues, and improving the stability and reliability of the system.

[0228] 4. Easy operation for developers and administrators

[0229] 1. For developers and system administrators, the second probe monitoring presents the configuration information, restart status and other data of online IDEs, providing them with a clear online IDE operation view. They can intuitively understand the actual operation status of each online IDE, and make configuration adjustments and troubleshooting when necessary, which improves the convenience and effectiveness of their online IDE management.

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

[0231] In a specific application scenario, the following technical process can be used to implement the configuration management module to monitor the online IDE instances of the first online IDE and the second online IDE respectively running in the first underlying editing environment and / or the second underlying editing environment through the created second probe, thereby achieving the functions of determining the first configuration information of the first online IDE, the second configuration information of the second online IDE, detecting whether the first online IDE is restarted, detecting 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 its version, etc.:

[0232] Regarding the creation and initialization of the second probe, according to the monitoring goal of the first online IDE and the second online IDE running instances 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 method 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 the data structure related to its internal configuration, and perceive the changes in the running status of the IDE instance in real time to determine whether to restart, etc.

[0233] According to the online IDE involved (such as one developed based on a specific programming language or platform) and the characteristics of the underlying editing environment, a suitable technical framework 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 APIs available for calling, you may choose a Java-related monitoring framework (such as Java Management Extensions-JME) combined with a specific network communication library (such as Apache HttpCl ient used to establish a network connection with the IDE instance) to implement the probe function. For Web-based online IDEs, you may choose a framework suitable for Web monitoring (such as Prometheus combined with related Web client libraries to monitor various indicators of Web services, which can be expanded here to monitor online IDE related information). At the same time, considering the need to adapt to different underlying editing environments and their versions, it is necessary to choose technologies with good compatibility and scalability so that they can be appropriately adjusted and configured according to the specific environment.

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

[0236] In order to establish a connection with the online IDE instance, the second probe needs to perform corresponding protocol adaptation according to the network communication protocol (such as HTTP, HTTPS, RPC, etc.) adopted by the online IDE instance. If it is the HTTP / HTTPS protocol, the probe may need to send a monitoring request to the IDE instance by constructing a suitable HTTP request header, request body, etc., and process the response from the IDE instance. For the RPC protocol, the probe needs to follow the corresponding RPC call specification to interact with the IDE instance through remote procedure calls. For example, if the first online IDE uses the HTTP protocol for internal communication and external services, the second probe needs to construct a request containing the correct request method (such as GET, POST, etc.), request path (pointing to relevant endpoints such as obtaining configuration information or checking restart status) and necessary request parameters in accordance with the HTTP protocol specification to accurately obtain the required information.

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

[0238] With respect to determining 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 under the first underlying editing environment. Different online IDEs and underlying editing environments may have different configuration information storage methods. For example, some may store configuration information in the form of files in a specific directory, while others 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 called config.xml, while configurations such as compiler options may be stored in another file called 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 relevant database tables (if database storage is used).

[0239] According to the identified configuration information storage structure, the second probe uses a corresponding method to obtain the configuration information content. If the configuration information is stored in a file, the probe may use a file reading operation (such as a regular text reading function for a text format file, and a specific binary reading function for a binary format file) 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 the 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 obtain the required configuration information records by sending SQL query statements (designed according to the database type and table structure) and convert them into a processable structured data form.

[0240] With respect to determining the second configuration information of the second online IDE, similar to determining the first configuration information of the first online IDE, after establishing a connection with the second online IDE instance, the second probe needs to identify the configuration information storage structure of the second online IDE under the second underlying editing environment. Similarly, different IDEs and underlying editing environments may lead to different storage methods, and the probe needs to determine the configuration file location and storage format 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 formatted 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 and debugger settings.

[0241] In order to detect whether the first online IDE is restarted, the second probe interacts with the operating system or runtime environment where the first online IDE instance is located, and monitors the state changes of the first online IDE process to determine whether it is restarted. It can regularly check the existence, running status (such as whether it is in running, suspended, terminated, etc.) and process ID and other information of the first online IDE process. For example, in a Linux environment, the second probe can use Linux's process management tools (such as the ps command) or related process monitoring APIs to obtain the status information of the first online IDE process. If it is found in a certain monitoring that the first online IDE process existed before but now disappears, and then a process with similar characteristics (such as the same executable file name, similar startup parameters, etc.) reappears, then it can be preliminarily determined that the first online IDE has been restarted.

[0242] In addition to monitoring process status 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 to restart. Many operating systems and online IDEs themselves will record some important operating events, such as start, stop, restart, etc., in the system log.

[0243] The second probe searches these log files (depending on the log storage location and format of different operating systems and IDEs) to find related records about the restart of the first online IDE. For example, in a Windows environment, the start and stop event records of the first online IDE may be searched in the Windows event viewer to determine whether a restart has occurred by analyzing the time sequence and content of these records.

[0244] To detect whether the second online IDE has been restarted, similar to detecting whether the first online IDE has been restarted, the second probe determines whether it has been restarted by monitoring the state changes of the second online IDE process and analyzing the log files or related event records of the system where it is located. It will regularly check the existence, running status, process ID and other information of the second online IDE process, and search the corresponding system log files or event records to find the restart-related records of the second online IDE, and determine whether a restart has occurred by comprehensively analyzing this information.

[0245] In order to ensure that the second probe is adapted to the underlying editing environment and its version, the first underlying editing environment and / or the second underlying editing environment and its version need to be detected when creating and initializing the second probe. This can be achieved in a variety of ways, such as querying the version information of the IDE itself (usually by sending a specific query request to the IDE or reading the IDE's metadata file), or by interacting with the specific API of the underlying editing environment to obtain relevant version information. Based on 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 specific 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 to ensure that monitoring operations can be accurately performed 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 the environment version update status (through methods similar to the above to obtain version information) and adjusting the probe's own code logic, communication protocol, etc. according to the update status. For example, when the underlying editing environment is upgraded from one version to another, and some new APIs or feature changes appear, the second probe will update its own code in a timely manner, adopt new APIs or adjust communication methods, etc., to ensure that it can still accurately perform monitoring operations under the new environment version and maintain its adaptability with the underlying editing environment and its version.

[0247] In addition to creating a second probe to determine the configuration information of the online IDE, detect whether to restart, and ensure the adaptation of the underlying editing environment and its version, the following equivalent alternatives can also be used:

[0248] 1. Extend the implementation using the built-in monitoring and feedback mechanism of the IDE

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

[0250] 2. If the existing feedback mechanism of the IDE cannot directly provide complete required information, you can consider expanding and developing the feedback interface of the IDE. By adding a custom code module (possibly in the form of a plug-in) inside the IDE, it can 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 plug-in that can read the configuration parameters of each module inside the IDE, and organize them into a format that is easy to obtain and analyze externally, and output them through the existing plug-in interface of the IDE or the newly added specific interface, thereby realizing the function of obtaining configuration information. For detecting the restart status, you can set a timer in the plug-in to regularly check the process status of the IDE and feedback the restart status through the interface.

[0251] 2. Monitoring and analysis based on proxy server

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

[0253] 2. For different monitoring needs, it is necessary to configure corresponding analysis rules and logic on the proxy server. For obtaining configuration information, you can set rules to let the proxy server pay attention to specific configuration file download requests, configuration-related API calls and other network activities. Once traffic that meets these rules is detected, a detailed analysis is performed to extract the configuration information. For detecting whether to restart, the proxy server can set up corresponding judgment logic based on the different network traffic patterns when the IDE is running normally and when it is restarted (such as the possibility of a large number of network connections being established or disconnected in a short period of time during restart), and judge whether the IDE is restarted by analyzing changes in network traffic.

[0254] 3. 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 time, error information during operation, etc. For example, in a Linux environment, system logs are usually stored in multiple files in the / var / log directory, such as sys log, messages, etc., from which records related to the online IDE need to be filtered out. The IDE itself may also have its own dedicated log files, such as the ide.log file in a specific directory, which may record more detailed information about the configuration and operation status.

[0256] 2. Parse the collected system logs, and use corresponding parsing methods (such as regular expression parsing, XML parser, etc.) according to the formats of different log files (such as text format, XML format, etc.) to convert their contents into analyzable structured data forms. The online IDE can be monitored by analyzing these structured data. For obtaining configuration information, you can find records about configuration changes from the log, such as the modification time and modification content of the configuration parameters, so as to construct the current configuration information. For detecting whether to restart, you can determine whether to restart based on the timestamp records of IDE start and stop in the log to determine whether there are continuous start and stop records.

[0257] Optionally, the configuration management module reads and records the first configuration information and / or the first configuration information through the created configuration loader, and reads and records the restart status of the first online IDE or the second online IDE, 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 restarted successfully.

[0258] To this end, the configuration management module implements related functions through the created configuration loader, which brings the following technical benefits in terms of improving configuration management efficiency, ensuring configuration consistency, simplifying developer operations, and facilitating system management and maintenance:

[0259] 1. 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 an accurate and detailed grasp of the configuration of the online IDE. This allows subsequent management, maintenance, and troubleshooting to be performed based on the accurately 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 changes in the running status of the IDE in real time. This is very important for timely discovering potential problems, evaluating system stability, and reasonably arranging subsequent operations (such as loading configuration after a successful restart, etc.), which helps to maintain the normal operation of the system.

[0262] 2. Ensure the consistency and effectiveness of configuration

[0263] 1. After the first online IDE or the second online IDE is successfully restarted, the configuration loader can automatically load the corresponding first configuration information or second configuration information. This function ensures the consistency of the configuration before and after the restart, so that the online IDE can quickly return to the previous working state after the restart, without manual reconfiguration, greatly improving development efficiency and reducing operational problems caused by configuration errors or omissions.

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

[0265] 3. Simplify developer operations

[0266] 1. Developers do not need to spend time and energy to re-set configuration parameters after restarting the IDE. The configuration loader will automatically complete the configuration loading work. This simplifies the operation process of developers, allowing them to focus more on code development itself and improve development efficiency.

[0267] 2. For developers, this automatic configuration loading mechanism provides a convenient user experience. They can restart the IDE with more confidence, knowing that the system will automatically restore to the appropriate configuration state after the restart, without having to worry about the tedious tasks related to configuration, thus improving their satisfaction with the entire online code development system.

[0268] 4. Easy system management and maintenance

[0269] 1. The configuration management module records and manages configuration information and restart status in a unified manner through the configuration loader, which is convenient for system administrators to conduct centralized monitoring and management. Administrators can quickly understand the system configuration status and IDE operation status by viewing relevant records, and promptly discover and solve possible problems, which improves the convenience and efficiency of system management.

[0270] 2. When a system failure or configuration anomaly occurs, the accurately recorded configuration information and restart status can provide important basis for troubleshooting. Administrators can analyze the problem based on these records and quickly restore to the normal configuration state through the automatic loading function of the configuration loader, shortening the troubleshooting and recovery time and reducing the impact of system failures on development work.

[0271] In a specific application scenario, the following technical implementation process can be used to realize 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 situation through the created configuration loader, and automatically load the corresponding configuration information after the IDE restarts successfully, thereby ensuring the 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 of reading and recording the first configuration information and / or the second configuration information, reading and recording the IDE restart status, 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 databases, configuration files, etc.) to complete various tasks. For example, it is determined that the configuration loader should have an interface that is compatible with different underlying editing environments so that relevant configuration information can be accurately obtained and set; at the same time, the internal data structure is designed to store configuration information, restart status records, etc., to facilitate subsequent processing.

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

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

[0275] After the configuration loader is created, initialization settings are performed. This includes establishing connections with the first online IDE and the second online IDE, and configuring connection parameters such as network address, port number, authentication information (if any), etc., so as to obtain the running status and related configuration information of the IDE in real time. At the same time, the data structure used to store configuration information and restart status records is initialized, such as creating appropriate arrays, linked lists, hash tables and other data structures, and setting the initial value to empty or the default value, in preparation for subsequent recording 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 stored in JSON format or XML format), or it may be stored in a database on a remote server (such as MySQL, PostgreSQL, etc.).

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

[0278] Depending on how the configuration information is stored, the configuration loader uses the corresponding reading method. If the configuration information is stored in a file, such as in JSON format, the configuration loader uses a JSON parsing library to read the file content and convert the parsed configuration information into a structured data form that can be processed internally (such as an object in Java, a dictionary in Python, etc.).

[0279] If the configuration information is stored in a database, the configuration loader will use a database connection library (such as JDBC for Java, SQLAlchemy for Python, etc.) to establish a connection with the database, and then obtain the required configuration information by sending SQL query statements (designing query statements based on the database table structure and the configuration information to be obtained), and convert it into a structured data form that can be processed internally.

[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 configuration information, a 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 in the hash table as the value. In this way, when the configuration information needs to be queried, updated, or used later, accurate configuration information can be easily obtained from the data structure, which also facilitates the management and maintenance of the configuration information.

[0281] In order to read and record the restart status 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 a continuous connection with the online IDE. It can be implemented in many ways, such as regularly checking the process status of the IDE, and when it is found that the process disappears and reappears and meets the restart characteristics, it is determined to be an IDE restart; 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 status. For example, in the Windows environment, the configuration loader can use the Windows process management API to regularly check the process status of the online IDE to monitor whether it has restarted.

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

[0283] Regarding the automatic loading of corresponding configuration information after the IDE is successfully restarted, after the configuration loader learns that the IDE has been restarted, it will first confirm whether the restart is successful based on the recorded restart status data structure. It will search for the restart record of the corresponding IDE (the first online IDE or the second online IDE) to check whether the restart is successful. If it is marked as "true", it means that the restart is successful and subsequent configuration loading operations can be performed. For example, find the restart record of the first online IDE from the array that stores the restart status record. If the restart success is marked as "true", proceed to the next step.

[0284] Once the restart is confirmed to be successful, the configuration loader obtains 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 is restarted successfully, the entire content of the first configuration information is obtained from the data structure storing the first configuration information (such as a hash table), and converted into a format applicable to the IDE (such as converting the internal structured data into JSON format or XML format, etc. according to the requirements of the IDE).

[0285] Finally, the configuration loader loads the acquired configuration information into the successfully restarted IDE. This may involve an interactive interface with the IDE (such as sending the configuration information to the IDE by sending an HTTP PUT request, or calling the IDE's API for setting configuration information, etc.), and applying the configuration information to the IDE's operating environment according to the IDE's setting process. For example, through the RESTful API provided by the IDE, the configuration loader sends the configuration information to the IDE in JSON format. After receiving the configuration information, the IDE will apply the new configuration information to its own operating environment according to its own internal mechanism (such as updating local configuration files, records in the database, etc.), thereby completing the configuration information loading operation.

[0286] Figure 2 This is a schematic diagram of the structure of a loader module according to an embodiment of the present application. Figure 2 As shown, the plug-in management module is connected to a first online IDE that performs online editing of a first code and has a first underlying editing environment, and a second online IDE that performs online editing of a second code and has 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 accordingly manages the plug-ins in at least one of the following ways:

[0287] Monitoring a first bottom-level editing environment of the first online IDE and a second bottom-level editing environment of the second online IDE to determine a plug-in that has taken effect;

[0288] Monitor plug-in update actions and plug-in addition actions. When a plug-in update action is detected, update the effective plug-in based on the association relationship; when a plug-in addition action is detected, add the plug-in based on the association relationship. The first underlying editing environment is different from the second underlying editing environment.

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

[0290] Optionally, the plug-in management module includes a first probe, which 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, so as to read the property information of all the plug-ins, determine the plug-ins that have taken effect, and monitor plug-in update actions and plug-in addition actions.

[0291] Optionally, the plug-in management module includes a plug-in loader, which is used to monitor plug-in update actions and plug-in addition actions, respond to the plug-in update action to update the effective plug-in based on the association relationship, and respond to the plug-in addition action to add a plug-in based on the association relationship, and reload the effective plug-in 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 plug-in loader.

[0292] Figure 3 This is a schematic diagram of the structure of a loader module according to an embodiment of the present application. Figure 3 As shown in the above Figure 2 Based on the embodiment, the loader module also includes: a configuration management module, which is used 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.

[0293] Optionally, the configuration management module includes a second probe, which is used 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, so as 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 also includes: a configuration loader, which is used to read and record the first configuration information and / or the first configuration information from the second probe, and read and record the restart status of the first online IDE or the second online IDE, 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 restarted successfully.

[0295] The present application embodiment provides a computer storage medium, on which a computer executable program is stored. When the computer executable program is run, a set 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 and editing in the following manner:

[0296] Monitor the first underlying editing environment and the second underlying editing environment, determine the plug-in that has taken effect, monitor the plug-in update action and the plug-in addition action, respond to the plug-in update action to update the plug-in that has taken effect based on the association relationship, and respond to the plug-in addition action to add a plug-in based on the association relationship;

[0297] Among them, there are a first online IDE, a second online IDE, and a 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. The first underlying editing environment is different from the second underlying editing environment.

[0298] The exemplary description of the above plug-in management module and computer storage medium can be found in the above Figure 1 The records are not repeated here.

[0299] It should be noted that the same or similar parts between the various embodiments in this specification can be referred to each other, 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, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments. The device and system embodiments described above are merely schematic, wherein the modules described as separate components may or may not be physically separated, and the components indicated as modules may or may not be physical modules, that is, they may be located in one place, or may be distributed on multiple network modules. It is suspected that some or all of the modules are selected according to actual needs to achieve the purpose of the scheme of this embodiment. It is suspected that ordinary technicians in this field can understand and implement it without paying creative labor.

[0300] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions that can be easily thought of by a person skilled in the art within the technical scope disclosed in the present application should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. An online code development system, characterized in that: The system comprises a first online IDE, a second online IDE and a plug-in management module, wherein 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 to the first online IDE and the second online IDE, the plug-in management module has an association relationship with all plug-ins available under the first underlying editing environment and the second underlying editing environment so as to manage the plug-ins in at least one of the following ways: monitoring the first underlying editing environment and the second underlying editing environment, determining the plug-ins that have taken effect, monitoring the plug-in update action and the plug-in addition action, responding to the plug-in update action to update the plug-in that has taken effect based on the association relationship, and responding to the plug-in addition action to add a plug-in based on the association relationship.

2. An online code development system according to claim 1, characterized in that: The plug-in management module is also used to read the attribute information of all the plug-ins to maintain all the plug-ins, and the attribute information includes: basic information of the plug-in, the version of the plug-in, the applicable environment of the plug-in, and the environment-applicable version of the plug-in; if the attribute information fails to be read, an independent verification instance will be created to load the plug-in corresponding to the failure to read the attribute information onto the independent verification instance for operation, and obtain the attribute information of the corresponding plug-in based on the result of the operation.

3. An online code development system according to claim 2, characterized in that: The plug-in management module is further used to reload the plug-in that has taken effect on 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.

4. An online code development system according to claim 2, characterized in that: The plug-in management module obtains the attribute information of all plug-ins through the plug-in reader, and when the attribute information reading fails, creates an independent verification instance to run the plug-in corresponding to the reading failure and obtains the attribute information of the corresponding plug-in according to the result of the running.

5. An online code development system according to claim 2, characterized in that: 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 created first probe, so as to read the property information of all the plug-ins, determine the plug-ins that have taken effect, and monitor the plug-in update actions and plug-in addition actions.

6. An online code development system according to claim 3, characterized in that: The plug-in management module monitors plug-in update actions and plug-in addition actions through the created plug-in loader, responds to the plug-in update action to update the effective plug-in based on the association relationship, responds to the plug-in addition action to add the plug-in based on the association relationship, and reloads the effective plug-in 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 plug-in loader.

7. An online code development system according to any one of claims 1 to 6, characterized in that: The online code development system also includes: a configuration management module, which is used 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.

8. An online code development system according to claim 7, characterized in that: 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 respectively through the created 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 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 their versions.

9. A loader module, characterized in that: The loader module is connected to a first online IDE that performs online editing of a first code and has a first underlying editing environment, and a second online IDE that performs online editing of a second code and has 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 accordingly manages the plug-ins in at least one of the following ways: Monitoring a first bottom-level editing environment of the first online IDE and a second bottom-level editing environment of the second online IDE to determine a plug-in that has taken effect; Monitor plug-in update actions and plug-in addition actions. When a plug-in update action is detected, update the effective plug-in based on the association relationship; when a plug-in addition action is detected, add the plug-in based on the association relationship. The first underlying editing environment is different from the second underlying editing environment.

10. A computer storage medium, characterized in that: The computer storage medium stores a computer executable program, which, when executed, implements the set plug-in management logic to interact with the first underlying editing environment and the second underlying editing environment to perform plug-in management and editing in the following manner: Monitor the first underlying editing environment and the second underlying editing environment, determine the plug-in that has taken effect, monitor the plug-in update action and the plug-in addition action, respond to the plug-in update action to update the plug-in that has taken effect based on the association relationship, and respond to the plug-in addition action to add a plug-in based on the association relationship; Among them, there are a first online IDE, a second online IDE, and a 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. The first underlying editing environment is different from the second underlying editing environment.

Images