High-performance runtime parsing and editing in a client-server model

Abstract

Embodiments of the present invention relate to high-performance runtime parsing and editing in a client-server model. The system receives a first request from a client for a document parsed based on syntax. The system parses and returns an initial number of lines of the document, allowing the client to display the initial number of parsed lines in a visual window. After successfully parsing the remaining lines, the system stores the fully parsed version. In response to scrolling in the visual window, the system provides the relevant portion of the unparsed document associated with the first request. In response to detecting the termination of scrolling, the system receives a second request for the parsed lines corresponding to the first set of lines. The system returns the corresponding parsed line, allowing the client to display the corresponding parsed line in the visual window.

Description

Technical Field

[0001] This disclosure generally relates to the field of data management. More specifically, this disclosure relates to methods and systems for facilitating high-performance runtime parsing and editing in client-server models. Attached Figure Description

[0002] Figure 1 The illustration depicts entities and communications that facilitate high-performance runtime parsing and editing in a client-server model, according to aspects of this application.

[0003] Figure 2A The illustration depicts communication that facilitates high-performance runtime parsing and editing (including loading and scrolling operations) in a client-server model according to aspects of this application.

[0004] Figure 2B The illustration depicts communication that facilitates high-performance runtime parsing and editing (including search, redirection, editing, and difference-based response operations) in a client-server model according to aspects of this application.

[0005] Figure 2C The illustration depicts communication that facilitates high-performance runtime parsing and editing (including undo, delayed synchronization, and file copying operations) in a client-server model according to aspects of this application.

[0006] Figure 3 The illustration shows a visual editor window with the requested configuration file according to an aspect of this application.

[0007] Figure 4A The diagram illustrates a flowchart of a method (including client-side operations) for promoting high-performance runtime parsing and editing in a client-server model according to aspects of this application.

[0008] Figure 4B The diagram illustrates a flowchart of a method (including server operations) for promoting high-performance runtime parsing and editing in a client-server model according to aspects of this application.

[0009] Figure 5 The illustration depicts a computer system that facilitates high-performance runtime parsing and editing in a client-server model, according to aspects of this application.

[0010] Figure 6 The illustration depicts an apparatus for promoting high-performance runtime parsing and editing in a client-server model according to aspects of this application.

[0011] In the figures, the same reference numerals indicate the same figures elements. Detailed Implementation

[0012] The following description is presented to enable any person skilled in the art to make and use the aspects and examples, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed aspects will be apparent to those skilled in the art, and the general principles defined herein can be applied to other aspects and applications without departing from the spirit and scope of this disclosure. Therefore, the aspects described herein are not limited to those shown, but should be given the broadest scope based on the principles and features disclosed herein.

[0013] Users (such as network administrators) can view and edit network configuration files for multiple network devices via an interactive editor based on a client-server architecture. In this architecture, users submit requests to view network configuration files for multiple network devices via a graphical user interface on a client display, and the server can parse the network configuration files based on a predefined syntax. Users can also generate edits (e.g., add, modify, delete) associated with one or more lines in the network configuration file and transmit those edits to the server. For example, an edit can be associated with multi-line operations, such as adding (pasting) twenty lines at once, or deleting multiple lines by selecting and deleting a block. The server can respond to a viewing request by using syntax to merge, process, and parse (hereinafter referred to as "parse") the requested network configuration file to obtain a fully parsed version. Similarly, the server can respond to an edit request by parsing the network configuration file based on the edits to obtain an updated, fully parsed version. However, there can be some challenges in such a client-server model. For example, large network configuration files (e.g., 10,000 lines per file) may cause the server to spend a significant amount of time parsing the network configuration file to obtain a similarly large parsed network configuration file. Furthermore, transmitting such a large, fully parsed network configuration file between the client and server can introduce delays.

[0014] The aspects described in this application provide a system that can provide an improved user experience for viewing and editing multiple large text-based network profiles. The described aspects can use techniques such as windowing, delayed synchronization, and difference-based response to more efficiently provide the parsed view to the user via a graphical user interface. This system can result in improved response time, reduced computational costs, and reduced network bandwidth consumption. The following is in conjunction with… Figure 1 It describes entities and communications that facilitate high-performance runtime parsing and editing in a client-server model.

[0015] The terms "network profile" and "profile" are used interchangeably in this disclosure and can refer to a document or file that stores, includes, or indicates settings related to or used for configuring one or more network devices. The term "network device" can refer to any computing device or entity operating on or associated with a network. In this disclosure, a network device can be associated with a network profile. Furthermore, while some aspects of this application describe "network profile," the described aspects can be applied to any document, file, document set, or collection of files governed by or based on syntax. That is, the terms "network profile" and "profile" are used as examples of documents or files parsed based on syntax. Other documents may be used. For example, the underlying parsing document may include Java source code files edited in an integrated development environment (IDE) where the files conform to a specific syntax, and where a user or system may wish to parse and view the files in an interleaved format to identify differences between files.

[0016] Facilitating high-performance runtime parsing and editing communication in a client-server model

[0017] Figure 1 The illustration 100 illustrates entities and communications that facilitate high-performance runtime parsing and editing in a client-server model according to aspects of this application. Illustration 100 may indicate an environment including: device 102, an associated user 112, and an associated display 114; device 104 and an associated or included storage device 105; and devices 106, 107, and 108 (e.g., switches). Devices 102, 104, and 106-108 may communicate with each other via network 110. Device 102 may be a client computing device, such as a laptop computer, mobile phone, smartphone, tablet, desktop computer, and handheld device. Devices 102, 104, and 106-108 may be computing devices, such as servers, networking entities, and communication devices. Devices 106-108 may be any network device associated with a configuration file, such as a server or switch. In some aspects, devices 102 and 104 (and their associated operations) may operate on the same device or within switches 106-108. Display 114 may include, instruct, or display various information to user 112 within a visual window of the editor. This visual window includes movable widgets and editing elements that can be activated or function to send commands to device 104. In other words, user 112 can perform actions 113 to activate any element indicated in display 114. User 112 may include a human user or an "automated user," such as a program interacting with an application programming interface (API).

[0018] For example, user 112 may want to view configuration files for one or more devices. User 112 can select a device (element 160) and perform action 113, such as loading a configuration (“config”) file for switch 106 (element 162). Device 102 can send a load configuration file command 126 to device 104. Device 104 can receive command 126 (as a request or load configuration file command 128). Device 104 can obtain configuration files for one or more devices (such as switches 106-108) before or after receiving request 128 (via communications 120, 122, and 124) (operation 130). Device 104 can process, parse, and merge (if necessary) the “initial” lines of the configuration file (operation 132). The initial lines can be the parsed and merged lines of the configuration initially presented or displayed to the user, such as the lines the user would initially expect to see on display 114 after performing action 113 via element 162 and before interacting with the displayed lines, as described below. Device 104 can send the parsed initial line 134 to device 102, while simultaneously, for example, processing, parsing, and merging the remaining lines of the configuration file concurrently as a background job (operation 138). Device 102 can receive the parsed initial line 134 (as parsed initial line 136) and (via element 176) perform action 111 to display the parsed initial line in a visual window. Therefore, user 112 can obtain a display view of the parsed initial line more quickly because the remaining lines can be parsed and returned by device 104 while user 112 is viewing the initial line.

[0019] At some point after device 104 begins operation 138 (concurrently parsing the remaining lines of the configuration file), once device 104 has successfully completed operation 138, device 104 can store a fully parsed version of the configuration file (operation 140) for access in response to subsequent requests or commands from device 102. Device 104 can return a fully parsed version 142 to device 102. Device 102 can receive the fully parsed version 142 (as a fully parsed version 144), which allows device 102 to perform action 111 to display any part of the fully parsed configuration file subsequently requested by user 112 (e.g., navigating to), and also allows user 112 to view the corresponding parsed line (element 176) in a visual window.

[0020] User 112 may wish to edit the configuration file, for example, by adding, modifying, or deleting one or more lines, and may generate an edit (element 170). Device 102 may send the edit to device 104 via edit configuration file command 146. Device 104 may determine and receive edit command 146 (as a request or edit configuration file command 148). Device 104 may parse the configuration file based on the edit and return an updated parsed configuration file (e.g., a new parsed copy of the configuration file) or with updated parsed lines (e.g., an increment or difference from a previous copy received by a client, such as via on-demand parsing operation 150). Device 104 may return the parsed corresponding line 152 to device 102. Device 102 may receive the parsed corresponding line 152 (as parsed corresponding line 154), which allows device 102 to perform action 111 for displaying the parsed corresponding line (via element 176).

[0021] User 112 may also wish to navigate within the configuration file, for example, by performing a scrolling, searching, or jumping action (via elements 164, 166, and 168, respectively). For instance, user 112 can navigate to a portion of the configuration file (whether via scrolling, searching, or jumping). Device 102 can send a corresponding command (e.g., navigation configuration file command 156) with a viewport identifier to device 104. Device 104 can receive the navigation command (via request or navigation configuration file command 158), determine the corresponding parsed line based on the viewport identifier, and either directly return the corresponding parsed line from the stored fully parsed version (if successfully stored) or perform on-demand parsing of the corresponding line (operation 150) and return the corresponding parsed line. Thus, as described above, device 104 can return the parsed corresponding line 152 to device 102. Device 102 can receive the parsed corresponding line 152 (as parsed corresponding line 154), which allows device 102 to perform action 111 for displaying the parsed corresponding line (element 176). The following is about... Figure 2A and Figure 2B It describes each navigation action in a specific navigation action (i.e., scrolling, searching, and jumping).

[0022] User 112 can also perform an undo action (element 172) and receive a fully parsed copy of the configuration file, the differences from the previous copy, or a portion of the configuration file. User 112 can also request a copy of the configuration file (element 174). The following is about... Figure 2C These operations are described.

[0023] Figures 2A to 2C The communication between client 206 and server 208, according to aspects of this application, facilitates high-performance runtime parsing and editing. Figure 2AThe illustration depicts communication 200 that facilitates high-performance runtime parsing and editing (including loading 210 and scrolling 220 operations) in a client-server model according to aspects of this application. Figure 2B The illustration depicts communication 201 for high-performance runtime parsing and editing (including search 230 operation, jump 240 operation, edit 250 operation and difference-based (“diff-based”) response operation 260) in a client-server model according to aspects of this application. Figure 2C The illustration depicts communication 202 that facilitates high-performance runtime parsing and editing (including undo 270 operation, delayed synchronization (“sync”) 280 operation, and file copying 290 operation) in a client-server model according to aspects of this application.

[0024] Add windows

[0025] Given a configuration file with 10,000 lines, a user associated with client 206 might want to edit the configuration file but only view 50 lines in a visible window on the client device's monitor. Instead of parsing all 10,000 lines at once, client 206 can send a visible window identifier to server 208, allowing server 208 to parse and return only the lines corresponding to the visible window identifier. For example, if the user only views lines 40 through 90 in the visible window, client 206 can generate and transmit requests for the corresponding parsed lines from the configuration file, such as `<start=40, end=90>`. The system can use the visible window identifier in at least two scenarios: initial loading and live editing.

[0026] - Initial loading

[0027] like Figure 2A As described in loading operation 210, a user can request to view a single configuration file, for example, by performing a user action in the editor window of the display (such as clicking the "View" or "Load" button on the graphical user interface). This can cause client 206 to perform configuration file loading operation 211. The initial loading of 10,000 lines of configuration file can result in costly computational operations. Server 208 can retrieve all 10,000 lines, parse them, match each line based on a predefined syntax (e.g., match each line with a suitable line specification), and return the parsed result to client 206. The predefined syntax can be based on a line specification, which can be associated with a specific command variant in the configuration file. The line specification can use some syntax or grammar to represent the lines of the configuration file and can specify the keywords, items, and values ​​that can appear for a given configuration command.

[0028] If a user requests to view multiple profiles for multiple devices (e.g., by performing a user action on the display), server 208 may need to perform the same retrieval and parsing process for each profile, and additionally merge the parsed profiles before returning the parsed results to client 206. Client 206 can receive the parsed results as a response and can build decorations for each line in the response. While these client and server operations occur, the user must wait for a response to their action (e.g., a button click). Any improvement in response time can lead to an improvement in the overall user experience.

[0029] When client 206 receives the parsed result as a response, client 206 can load the parsed result and display it in the visual editor window of the display. After the initial loading, the user will only view a subset of all lines of the configuration file, typically only the first N lines of the configuration file, where N is associated with the average number of lines displayed in the visual window. Therefore, the described aspect can use a two-stage loading process. The client can send a request 212 to server 208 to load a configuration file for at least one device. In the first stage, server 208 can receive request 212 and only retrieve, parse, and merge the first N lines of each requested configuration file (parsing and merging initial lines operation 213) and subsequently return the parsed first N lines to client 206 (parsed initial lines 215) for display in the visual window. Server 208 can also store the parsed initial lines (operation 214). Because some lines can be filtered or collapsed in the client editor's visual window, the system can load N+M lines, where M is the additional number of lines loaded due to the expectation of filtered / collapsed lines. In this case, N can be the actual number of rows displayed in the visual window (and is also associated with the average number of rows displayed in the visual window). Client 206 can store and display the parsed initial row (operations 216 and 217). In some aspects, server 208 can return an unparsed configuration file 296, and client 206 can store the unparsed configuration file (operation 297). The unparsed configuration file can be associated with a single switch, and in the case of multiple configuration files, it can be randomly selected or selected based on characteristics of multiple configuration files (e.g., the longest configuration file). The unparsed configuration file can be sent as a separate response (as shown in 296) or it can be sent as part of the parsed initial row 215.

[0030] In the second phase, which can be executed in parallel with the first phase, server 208 can initiate a background job that performs the same process (parsing and merging remaining lines operation 218) on the remaining lines of the configuration file (or on the entire configuration file). Server 208 can also store the fully parsed version (operation 219) and return the fully parsed version 267 to client 206. After storing the fully parsed version of the configuration file (operation 219), server 208 can also create and store an anchor link table (operation 266), which can be used in subsequent jump actions, as described below. Figure 2B The jump 240 operation is described.

[0031] Client 206 can receive and store the fully parsed version (operation 268). Although this background job (218) may take longer to complete than the initial parsing of the first N rows (213), the system can replace the incomplete initial result (the initial response with the first N rows parsed) from the first stage with the complete result (the fully parsed version) from the second stage. This allows client 206 to receive the initial response (215) in a shorter amount of time than receiving the fully parsed version (267) of the second response, which can lead to an improved user experience. Client 206 has likely already received the second response when the user begins to interact with the first response (e.g., through clicks, navigation, scrolling, searching, etc.). In some respects, the system can provide optimizations such as omitting the first N rows included in the first stage in the second stage.

[0032] In practice, the difference in response time between the first and second stages can be approximately a few seconds. During this period, the user may want to scroll down and view other parts of the document. In some aspects, the system can extend the two-stage loading process to a three-stage, four-stage, or Y-stage loading process, where each stage can load and parse a proportionally larger percentage of lines in the document. The system can determine the number of stages based on the document size, default settings, or user-configured settings. For example, a document with more than 20,000 lines can use a four-stage loading process, while a document with fewer than 5,000 lines can use a two-stage loading process.

[0033] Live editing: navigation (scrolling, searching, and jumping) and undo operations

[0034] After loading the configuration file, users may want to edit it, for example, by adding, modifying, or deleting a line (“single edit”) or multiple lines (“multiple edits”). Figure 2BAs depicted in edit operation 250, a user can generate a first edit associated with rows in a row set within a visual window, which can trigger client 206 to perform a generate edit operation 251. The system or client 206 can then generate a request for an updated parsed row (or an updated, fully parsed configuration file) from server 208 based on the first edit (request for updated parsed rows based on edit 252). Server 208 can receive request 252, parse the configuration file based on the first edit (operation 253), and return either the updated, fully parsed configuration file or the updated parsed row corresponding to the visual row set (operation 254). In some aspects, the system or server 208 may return only the updated parsed row corresponding to the visual row set, instead of returning the updated, fully parsed configuration file. This can result in a reduction in response time, which in turn can lead to an improvement in the overall user experience. Client 206 can receive the updated parsed configuration file or the corresponding parsed line 255, store the updated parsed configuration file or the corresponding parsed line (operation 256), and display the updated parsed line (operation 257).

[0035] Users may want to navigate to another part of the document, for example, by scrolling, searching, or clicking on jumps or anchor links. In some aspects, (e.g., by estimating the viewport identifier), client 206 can estimate the position of the viewport within the document and transmit a request to server 208 for a portion of the parsed configuration file corresponding to the viewport. Server 208 can re-parse the requested portion of the configuration file, or, if the configuration file (or the requested portion) has already been fully parsed and stored / cached by server 208, return the stored / cached parsed portion.

[0036] scroll. like Figure 2AAs described in scrolling operation 220, when viewing or navigating a given configuration file, a user can scroll to a new location within the file. During the time spent physically or actively scrolling to a new location, the user typically does not examine the details of each line. Instead, the user may be scanning the overall document structure and looking for keywords or placeholders that indicate whether the user has reached the desired section of the document. For example, when scrolling through a configuration file to edit "Interface 1 / 1 / 22", the user can scroll past lines preceding the interface block, such as lines involving Simple Network Management Protocol (SNMP) or Virtual Routing and Forwarding (VRF). The user can reach lines following the interface block (such as lines involving routing protocols) and decide to terminate or stop scrolling and begin moving backward or backward within the document. Therefore, when the system detects a scrolling action performed by the user (i.e., during the time the user is scrolling) (operation 221), the described aspect may present an unresolved copy of the configuration file for a single switch (e.g., the unresolved configuration file 296 stored in operation 297) or a related or estimated portion of the unresolved copy (displaying the unresolved configuration file operation 222).

[0037] When the system detects that the user has stopped scrolling, i.e., when the user stops scrolling (operation 223), the client 206 can generate a request for the parsed section in the visual window (request 224 for the parsed line in the visual window) and send the request to the server. The server 208 can receive request 224. If the fully parsed version is stored or available to the server, the server 208 can retrieve the fully parsed version and return the corresponding parsed line (operation 225 and corresponding parsed line 226). If the fully parsed version is not stored or is not available to the server 208, the server 208 can parse the section in the configuration file corresponding to the line in the visual window (operation 225), and can also return the parsed section as the corresponding parsed line (corresponding parsed line 226). The client 206 can store and display the corresponding parsed line (operations 227 and 228).

[0038] Furthermore, users can scroll through large amounts of data within a short period, and the system can detect the amount of scrolling within a predetermined time window. In such a scenario, client 206 can generate a request for the parsed lines corresponding to the estimated viewport. Client 206 can estimate the viewport based on, for example, the scrolling speed based on the amount of scrolling within the predetermined time window; and an estimate of the percentage of the file or document that has been scrolled through during the predetermined time window. Using the estimated viewport, client 206 can transmit a request for the parsed lines corresponding to the estimated viewport to server 208.

[0039] search.like Figure 2B As described in search operation 230, when viewing or navigating a given configuration file, a user can search for items within the document (operation 231). If client 206 has already received and stored / cached the fully parsed version, client 206 can simply search the cached copy and display the relevant section (operation 236). If client 206 has not yet received and stored / cached the fully parsed version, client 206 can generate a request for the first match in the fully parsed version and send that request to server 208 (e.g., to obtain the first search result) (request for search results for an item 232). Server 208 can receive request 232. If the fully parsed version is stored or available to server 208, server 208 can search the fully parsed version and return the parsed line from the fully parsed version corresponding to the first hit (as the first search result) (operation 233 and parsed line for result 234). If the fully parsed version is not stored or is unavailable to server 208, server 208 can search the configuration file for the first hit and perform on-demand parsing of the line corresponding to the first hit (operation 233), and can also return the parsed line corresponding to the first hit (as the first search result) (parsed line 234 for the result). Client 206 can receive result 234 and can store and display the result (operations 235 and 236).

[0040] In some respects, when a fully parsed version is unavailable, client 206 can cache the first search result as well as subsequent search results, making it possible to perform navigation back and forth between item hits (i.e., search results) more efficiently than parsing the entire document.

[0041] Jump to the next page. like Figure 2BAs depicted in jump 240, when viewing or navigating a given profile, a user can jump to different locations in the same or another document by clicking a link (e.g., a reference, anchor, jump link, or anchor link associated with one or more lines). The system can associate one or more lines in one profile with an anchor in another profile (e.g., as a reference to an Internet Protocol (IP) address of another switch). Client 206 can send a reference to server 208 (click jump link operation 241) and request the resolved line corresponding to that reference in the window (request result 242 for jump link). Server 208 can receive request 242. Server 208 can use a pre-computed lookup table (such as created in operation 266) that maps a given reference to a window or set of lines that most efficiently displays the anchor. Server 208 can search the lookup table to find the given reference (operation 243) and return the mapped window (mapped window 244 with resolved lines) to client 206. Client 206 can receive the mapped window and can also store and display the mapped window with parsed lines in different locations in the same or another document (operations 245 and 246).

[0042] Typically, server 208 must have access to an available or stored / cached copy of the fully resolved version in order to precompute the lookup table, as described above regarding operations 218, 219, and 266. In some respects, if the fully resolved version is unavailable or not stored / cached, server 208 can use precomputed regular expressions to translate redirect links or references into searches.

[0043] Furthermore, jump links can resemble a table of content or "section entries." To create such a table of content or section entries, the system does not need to include the lowest-level rows (i.e., the rows with the most indentation in the configuration file's line hierarchy), because jump information is expected to appear at higher levels. Server 208 can perform more efficient parsing of anchors via pre-parsing or filtered parsing of one or more documents, where the system can remove or filter the lowest-level rows of the documents and parse only the remainder of one or more documents to identify the anchor (operation 243). For example, the system can omit parsing lines that begin with a certain number of spaces (such as two or four spaces) (or filter out lines before parsing).

[0044] Cancel. like Figure 2CAs depicted in Undo 270, after performing an editing operation, the user may wish to undo the editing operation. Client 206 can generate and request a reverse operation of the editing operation performed from the server, or request server 208 to perform an undo operation (Execute Undo 271 and Request Execution of Reverse or Undo Operation 272). In some cases, client 206 may not know all the information required to construct a reverse operation; in such cases, client 206 can send a request to server 208 to perform an undo operation (Request 272). Server 208 can receive Request 272. Server 208 can calculate the new state of the document (e.g., using a difference-based file) by performing a reverse or undo operation, as described below (Operation 273). This can occur, for example, when the user pastes multiple lines that can be mixed into various sections of the document, in which case client 206 may not have yet seen the modified lines outside the visible window; and when the user inserts a new line that can be combined with existing lines, in which case client 206 may not have yet recorded the previous state of the combined line. Server 208 can return the configuration file or visual parsed lines corresponding to the previous window state (previous window state 274) to client 206. Client 206 can store and display the previous window state as visual parsed lines (operations 275 and 276).

[0045] like Figure 2C As described in the file copying operation 290, in some respects, a user can copy the entire configuration file from the editing window, which may cause client 206 to perform copy operation 291. Client 206 may send a request to the server for a flattened version of the entire document (request for a copy of the configuration file 292). Server 208 may receive request 292, retrieve the flattened version of the configuration file (operation 293), and return the flattened version of the configuration file in its response (flattened version 294). Client 206 may receive and store the flattened version of the configuration file (operation 295).

[0046] Delayed Synchronization

[0047] The above operations may involve an iterative feedback loop, where user / client 206 allows and generates a single edit, transmits the single edit to server 208, and waits for a response from server 208 before allowing and generating further edits. In some aspects, the system may provide delayed synchronization between client 206 and server 208, where client 206 can allow and generate multiple edits. Client 206 can store these multiple edits in a queue and subsequently replay them to server 208. Client 206 can store multiple edits in the queue until client 206 detects a condition (operation 281), and can replay the edits to server 208 after detecting the condition. These conditions may include: determining a user activity delay greater than a predetermined time (e.g., based on a time period since the last user action performed via the graphical user interface); detecting that a user has generated a specific synchronization command via the graphical user interface (e.g., based on a user action such as clicking a "synchronize" button); detecting that a user is editing a section of the profile with more than a predetermined number of lines, in addition to multiple edits associated with multiple lines (e.g., based on a user action performed via the graphical user interface in a new context or region of the profile or based on the relative size of the profile); and determining that the length of the queue is greater than a predetermined size (e.g., based on how many edits the user has generated). Some of these conditions may include or be based on quantitative values, such as the length of the user delay or the size of the client queue. The system may dynamically tune the quantitative values ​​based on, for example, the length of the profile. For example, large documents may require longer to parse and update, so the system may dynamically increase the quantitative condition value for large documents.

[0048] When client 206 detects a condition (operation 282), client 206 can determine the order of transmission of edits to the server based on, for example, the following (operation 283): the order in which the user enters multiple edits; the order of multiple edits based on the order in which the edits occur in the configuration file; all add actions as a single batch paste operation; and all delete operations as a single batch delete operation. Client 206 can generate a request for updated parsed lines (request 284 for parsed lines based on ordered edits) and send the request to server 208. Server 208 can receive request 284, parse the configuration file based on ordered edits, and return the updated parsed configuration file or the updated parsed lines (operation 285 and updated parsed configuration file or corresponding parsed lines 286). Client 206 can receive the updated parsed configuration file or the updated parsed lines 286, store the updated parsed configuration file or the updated parsed lines (operation 287), and display the updated parsed lines (operation 288).

[0049] Because client 206 is already syntax-aware (e.g., knows the line specification), it can match the typed lines to the line specification. Client 206 can then sort the lines to a position within the document that is very close to where server 208 will sort the lines. Client 206 can also allow the user to edit per-document values ​​before sending the edits to server 208.

[0050] Difference-based response

[0051] As described herein, the system can return a fully parsed version of the configuration file (e.g., 267 and 255) to client 206, and client 206 can receive, store (e.g., 268), and navigate to any part of the fully parsed version (e.g., scrolling 220, searching 230, and jumping 240). However, in the case of a single edit or a few edits, most lines in the configuration file remain unchanged relative to other lines. Sending the entire file when only a single line or a few lines have changed can unnecessarily consume computational and network resources.

[0052] like Figure 2B As described in operations 250 (editing) and 260 (difference-based), after parsing the configuration file based on one or more edits (operation 253), server 208 can calculate, return, and store difference-based responses (operations 261 and 262) as a supplement to or replacement of operation 254. Client 206 can receive and store the difference-based responses (difference-based responses 263 and operation 264). Client 206 can also update the display based on the difference-based responses (operation 265).

[0053] Instead of parsing and returning the updated parsed lines or the fully parsed version (as in operation 253), server 208 can calculate the difference between the pre-edit and post-edited states of the configuration and return the calculated difference to client 206 (operation 261). Server 208 can also store the calculated difference (operation 262). The pre-edited state can be a first state corresponding to the state of the configuration file before one or more edits, while the post-edited state can be a second state corresponding to the state of the configuration file after one or more edits. Server 208 can store records of the calculated differences and use the stored records of the calculated differences to restore to a previous state, for example, if the client requests an undo operation.

[0054] Upon receiving the calculated difference (as a difference-based response 263), client 206 can determine the updated parsed row based on the visible row and the calculated difference or the difference-based response 263. Therefore, client 206 can update its own version and the display of parsed rows by using the calculated difference as a "recipe" for the change. This can result in a reduction in the amount of data sent from server 208 to client 206 and can also reduce the consumption of network resources. While the "calculated difference" (as calculated by server 208) and the "difference-based response" (as returned to client 206 and received by client 206) can be logically related, in some respects, different formats can be used for the calculated difference and the difference-based response. For example, the calculated difference may include implementation-internal information that may not be present in the difference-based response, and the difference-based response may include a request identifier or other communication or protocol-related information that may not be present in the calculated difference.

[0055] A visual editor window with the requested configuration file.

[0056] Figure 3 The illustration 300 illustrates an aspect of this application, featuring a visual editor window 301. Illustration 300 can be used with... Figure 1 The display 114 corresponds to and may include various movable widgets and editing elements for users of client devices. Illustration 300 may include an area where the user can load a profile (element 310) by selecting one or more devices (elements 314 and 316), and may also display the number of devices selected from the total available devices (element 312). A user request to load a profile for two selected devices may trigger the above-mentioned... Figure 2A The operation described in loading 210.

[0057] The system can load the initial lines into the visual window editor 301 (e.g., visual lines 1 to 13). Users can edit and browse the loaded configuration files and perform other actions. For example, users can perform navigation (via elements 320, 322, and 324 or other keyboard input) by scrolling, which leads to the above-mentioned... Figure 2A The operation described in scroll 220. Users can also perform a search by typing an item in the search box (element 332) and clicking the search button (element 330), which leads to the above description of... Figure 2B The operation described in search 230.

[0058] Certain text can be highlighted or displayed to indicate clickable jump links. For example, text 340 may include an item "interface" (element 340) with underlines or other indicators such as color or font changes on mouse hover. Users can also perform navigation by clicking element 340, and the system can update the visual window editor 301 to display previously mapped windows for reference in element 340, as described above for... Figure 2B The jump to 240 is described.

[0059] Users can edit one or more rows in the displayed visual window, for example, by inserting row 8 (element 350) before row 9. To send a request for the updated, parsed row to the server after the user has finished editing, the user can click the submit button (element 352), or the system can automatically generate a request for the updated, parsed row based on another user action, such as pressing "enter" or "tab" on the keyboard after editing the row. This triggers the request mentioned above for... Figure 2B The operation described in Edit 250.

[0060] Users can also undo previous edits by selecting the undo button (element 370), which raises the question raised above regarding... Figure 2C The undo operation described in 270. Users can copy the configuration file (and receive a flattened copy) by selecting the Copy Configuration File button (element 390), as described above. Figure 2C The operation described in file 290 is the copying of the file.

[0061] Furthermore, users can perform multiple edits (e.g., across multiple lines 380) and the system can perform delayed synchronization operations, as described above. Figure 2C The delayed synchronization 280 describes the operation. In some aspects, the user can select the delayed synchronization conditions (element 380), that is, the conditions that trigger the transmission of multiple edits in the queue to the server. The user can also select the order in which the multiple edits in the queue are transmitted to the server (element 382). In some aspects, the system (e.g., client 206 or software running on client 206) can determine the order in which the edits in the multiple queues are transmitted. The system can also determine the conditions and order based on predefined user settings, system settings, or default settings.

[0062] Methods for facilitating high-performance runtime parsing and editing in client-server models

[0063] Figure 4AA flowchart 400 illustrating a method for facilitating high-performance runtime parsing and editing (including client operations) in a client-server model according to aspects of this application is presented. During operation, the system generates a first request via a user action from the client based on a graphical user interface on the client's display, thereby allowing the server to perform the following operations on a parsed document from the server: parsing an initial number of lines of the document; returning the parsed initial number of lines to the client while concurrently parsing the remaining lines of the document; and storing a fully parsed version of the document after successfully parsing the remaining lines (operation 402). In response to receiving the parsed initial number of lines, the system displays the parsed initial number of lines in a visual window of the display (operation 404). In response to detecting a scrolling action by the user via the graphical user interface, the system displays the relevant portion of the unparsed document associated with the first request in the visual window (operation 406). If the system does not detect the termination of the scrolling action (decision 408), the operation continues at operation 406.

[0064] If the system detects the termination of the scrolling action (decision 408), the system generates a second request for the parsed line corresponding to the first set of lines (e.g., in a visual window), thereby allowing the server to return the corresponding parsed line from a fully parsed version, or to return the corresponding parsed line from the section of the parsed document corresponding to the first set of lines (operation 410). In response to receiving the corresponding parsed line, the system displays the corresponding parsed line in a visual window, for example (operation 412), and the operation returns.

[0065] Figure 4B A flowchart 420 illustrates a method for promoting high-performance runtime parsing and editing (including server operations) in a client-server model according to aspects of this application. During operation, the system receives a first request from a client for a document parsed based on syntax (operation 422). As described above regarding... Figure 1As described by user 112, the first request (and other user or client requests) can be initiated by a human user (e.g., via an editor or graphical user interface (GUI) on the client or client display) or by an automated user (e.g., by a program via an API), allowing for both human and program control. Furthermore, the document can be a network configuration file, and the editor or GUI can run on a client that manages the configuration of network devices by editing the network configuration file. The system parses an initial number of lines of the document based on syntax (operation 424). The system returns the parsed initial number of lines to the client while concurrently parsing the remaining lines of the document, allowing the client to display the parsed initial number of lines in a visible window on the display (operation 426). After successfully parsing the remaining lines, the system stores a fully parsed version of the document (operation 428).

[0066] In response to a scrolling action in the visual window, the system provides the relevant portion of the unparsed document associated with the first request (e.g., for display in the visual window) (operation 430). If the system does not detect the termination of the scrolling action (decision 432), the operation continues at operation 430. If the system does detect the termination of the scrolling action (decision 432), the system receives a second request for the parsed lines corresponding to the first set of lines (e.g., in the visual window) (operation 434). The system returns the corresponding parsed line from the fully parsed version, or the section of the parsed document corresponding to the first set of lines to return the corresponding parsed line, thereby allowing the client to display the corresponding parsed line in the visual window (operation 436). The operation returns. Although in Figure 4A and Figure 4B The embodiments described are not depicted herein, but the described embodiments may include performing the above description of... Figure 1 , Figure 2A , Figure 2B and Figure 2C The method of the operation described.

[0067] Computer systems and devices

[0068] Figure 5The illustration depicts a computer system that facilitates high-performance runtime parsing and editing in a client-server model according to aspects of this application. The computer system 500 includes a processor 502, a network interface card (NIC) 504, volatile memory 506, and a storage device 508. The NIC 504 facilitates communication with other systems by connecting the computer system 500 to other networks. The volatile memory 506 may include, for example, random access memory (RAM) acting as managed memory, and may be used to store one or more memory pools. The storage device 508 may include a persistent storage device that can be managed or accessed via the processor 502. Furthermore, the computer system 500 may be coupled to peripheral input / output (I / O) user equipment 510, such as a display device 511, a keyboard 512, and a pointing device 514. The storage device 508 may store an operating system 516, a content processing system 518, and data 536. The computer system 500 may include... Figure 5 The modules shown are fewer or more modules, and can be used with servers (such as...) Figure 1 Device 104 or Figures 2A to 2C It is associated with server 208 in the middle.

[0069] Content processing system 518 may include instructions that, when executed by computer system 500, cause computer system 500 or processor 502 to perform the methods and / or processes described in this disclosure. Specifically, content processing system 518 may include instructions for receiving and transmitting data packets and instructions related to configuration files, requests, and commands (communication module 520).

[0070] Content processing system 518 may further include instructions for receiving a first request (communication module 520) from a client for a parsed document, which is parsed based on syntax. Content processing system 518 may include instructions for parsing an initial number of lines of the document based on syntax (configuration file / line parsing module 522). Content processing system 518 may include instructions for returning the parsed initial number of lines to the client (line return module 528) while concurrently parsing the remaining lines of the document (configuration file / line parsing module 522), thereby allowing the client to display the parsed initial number of lines in a visible window of the display. Content processing system 518 may include instructions for storing a fully parsed version of the document (file storage module 524) after successfully parsing the remaining lines (configuration file / line parsing module 522). Content processing system 518 may further include instructions for providing the relevant portion of the unparsed document associated with the first request (line return module 528) in response to scrolling in the visible window (file navigation / search module 526). Content processing system 518 may include instructions (communication module 520) for receiving a second request for parsed lines corresponding to the first set of lines in response to the detection of termination of scrolling action (file navigation / search module 526). Content processing system 518 may also include instructions for returning the corresponding parsed lines from a fully parsed version (line return module 528), or for parsing the section of the document corresponding to the first set of lines to return the corresponding parsed lines (configuration file / line parsing module 522), thereby allowing the client to display the corresponding parsed lines in a visual window.

[0071] The content processing system 518 may also include instructions for responding to the following operations: navigation operations (file navigation / search module 526) for scrolling 220, searching 230 and jumping 240; editing operations (file editing module 528); undo operations (undo management module 530) for undoing 270; delayed synchronization operations (delayed synchronization management module 534) for delayed synchronization 280; and copy operations (communication module 520) for copying files 290.

[0072] Data 536 may include any data required as input or generated as output by the methods and / or processes described in this disclosure. Specifically, data 536 may store at least: syntax; lines; modified or unmodified lines; line specifications; requests; items; values; default values; keywords; documents; files; configurations; configuration files; unparsed copies or versions of documents, files, or configuration files; fully parsed copies or versions of documents, files, or configuration files; parsed lines; parsed sections of documents, files, or configuration files; initial number; number of stages; viewport identifier; viewport indicator; indicator for navigation, scrolling, searching, jumping, undoing, editing, copying, or delayed synchronization operations; indicator for whether a fully parsed version is available or stored; a scheduled time window; scrolling speed; and at a scheduled time. Scrolling amount during a window; estimate; percentage; one or more edits to one or more rows; row set; queue; multiple edits; condition; delay of user activity via the graphical user interface; scheduled time; scheduled number of rows; queue length; scheduled size; time period since the latest user action performed via the graphical user interface; new context or area of ​​a document, file, or configuration file; size of a document, file, or configuration file; multiple edits; order of edits; batch paste or delete operation based on multiple add or delete edits; difference; state of a document, file, or configuration file; state before editing; state after editing; and the calculated difference between the two states.

[0073] Figure 6 The illustration depicts an apparatus for promoting high-performance runtime parsing and editing in a client-server model according to aspects of this application. Apparatus 600 may include multiple units or devices that can communicate with each other via wired, wireless, quantum optical, or electrical communication channels. Apparatus 600 may be implemented using one or more integrated circuits and may include more than Figure 6 The shown unit or device may be fewer or more units or devices. Furthermore, device 600 may be integrated into a computer system, or implemented as one or more separate devices capable of communicating with other computer systems and / or devices.

[0074] Device 600 may also include a non-volatile memory system or a memory management unit. Device 600 may include components configured to perform similar functions. Figure 5 The computer system 500 includes modules or units 602-616 of modules 520-534 that function or operate, including: a communication unit 602; a configuration file / line parsing unit 604; a file storage unit 606; a file navigation / search unit 608; a line return unit 610; an undo management unit 612; a line editing unit 614; and a delay synchronization management unit 616.

[0075] In general, the disclosed aspects provide a system for facilitating high-performance runtime parsing and editing in a client-server model. In one aspect, during operation, the system receives a first request from a client for a document being parsed based on syntax. The system parses an initial number of lines of the document based on syntax. The system returns the parsed initial number of lines to the client, allowing the client to display the parsed initial number of lines in a visual window of the display. After successfully parsing the remaining lines of the document, the system stores a fully parsed version of the document. In response to a scrolling action in the visual window, the system provides the relevant unparsed portion of the document associated with the first request. In response to detecting the termination of the scrolling action, the system receives a second request for parsed lines corresponding to the first set of lines (e.g., in the visual window). The system returns the corresponding parsed lines from the fully parsed version, or parses the section of the document corresponding to the first set of lines to return the corresponding parsed lines, allowing the client to display the corresponding parsed lines in the visual window.

[0076] In one variation of this approach, the system returns the initial number of parsed lines while concurrently parsing the remaining lines of the document in one or more stages. After successfully parsing lines for a given stage, the system performs at least one of the following: storing the successfully parsed lines for that stage; and returning the successfully parsed lines for that stage, thereby allowing the client to perform at least one of the following: receiving the successfully parsed lines for that stage; and storing the successfully parsed lines for that stage.

[0077] In another variation of this aspect, in response to determining that a fully parsed version is stored or available, the system returns the corresponding parsed line from the fully parsed version. In response to determining that the fully parsed version is not stored or unavailable, the system parses the section of the document corresponding to the first set of lines and returns the parsed section as the corresponding parsed line.

[0078] In another variation, returning an initial number of parsed rows to the client also allows the client to store the initial number of parsed rows in response to receiving them, where the initial number of rows is associated with the display's visible window. Returning an initial number of parsed rows to the client also allows the client to store the corresponding parsed row in response to receiving it. The system returns a fully parsed version of the document to the client, thus allowing the client to store the fully parsed version of the document in response to receiving it.

[0079] In another variation, in response to determining that a scrolling action occurred during a predetermined time window, the system receives a third request for the parsed lines corresponding to an estimated viewport, wherein the estimated viewport is based on at least one of: a scrolling speed based on the amount of scrolling action during the predetermined time window; and an estimate of the percentage of the document that has been scrolled through, based on the amount of scrolling action during the predetermined time window. The predetermined time window may refer to the time window after receiving the initial response (i.e., the initial number of parsed lines) and before receiving the fully parsed version.

[0080] In another variation, the system determines a first edit associated with a row in a second set of rows (e.g., in a visual window). The system receives a fourth request based on this first edit, the fourth request targeting an updated parsed row corresponding to the second set of rows. The system parses the document based on the first edit. The system returns either the updated parsed document or the updated parsed row corresponding to the second set of rows, thereby allowing the client to perform at least one of the following in response to receiving the updated parsed document and the updated parsed row: storing the updated parsed document and the updated parsed row; and displaying the updated parsed row in a visual window.

[0081] In another variant, the system identifies multiple edits associated with multiple lines of a parsed document, with these edits stored in a queue on the client until a condition is detected, thus allowing the client to determine the order in which the edits are transmitted in response to the detection of that condition.

[0082] In another variation, the detection conditions include at least one of the following: determining that the user activity delay via the graphical user interface on the client is greater than a predetermined time period; detecting that the user has generated a specific synchronization command via the graphical user interface; detecting that, in addition to multiple edits associated with multiple lines, the user is editing a section of a document with more than a predetermined number of lines; and determining that the length of the queue is greater than a predetermined size.

[0083] In another variation, the condition is based on at least one of the following: a time period since the latest user action was initiated via the graphical user interface; a user action initiated via the graphical user interface in a region of the document that is different from the region associated with a visual window comprising multiple lines; the size of the document; and the number of multiple edits.

[0084] In another variation, editing includes at least one of the following: add operations, modify operations, and delete operations. The order in which edits are transmitted is determined based on at least one of the following: the order in which multiple edits are entered by the user; the order in which the multiple edits occur in the document; multiple edits submitted as a single batch edit operation; all add actions as a single batch paste operation; and all delete operations as a single batch delete operation.

[0085] In another variation, the system determines a second edit associated with a row in a third set of rows (e.g., in a visual window). The system receives a fifth request based on this second edit, the fifth request addressing the updated parsed row corresponding to the third set of rows. The system calculates a difference between a first state and a second state of the document, where the first state corresponds to the document's state before one or more edits, and the second state corresponds to the document's state after one or more edits. The system stores the calculated difference. The system returns the calculated difference to the client, allowing the client, in response to receiving the calculated difference, to: determine the updated parsed row based on the third set of rows and the calculated difference; store at least one of the calculated difference and the updated parsed row; and display the updated parsed row.

[0086] In another variant, the system uses the calculated difference to perform subsequent undo operations.

[0087] In another variation, the system determines user activation via a reference link through a graphical user interface on the client. The system receives a sixth request based on the user activation of the reference link, which is directed to a parsed line mapped to the reference link. In response to determining that a fully parsed version is not stored or is unavailable, the system: performs a filtered parsing of the document by omitting lines with indentation greater than a predetermined number of spaces; creates a lookup table based on the filtered parsing to map reference links to parsed lines; and returns the parsed lines mapped to reference links. In response to determining that a fully parsed version is stored or available, the system: searches the lookup table previously created based on the fully parsed version; and returns the parsed lines mapped to reference links, thereby allowing the client to display the parsed lines mapped to reference links in a visual window in response to receiving them.

[0088] In another variation, the first request is received via at least one of the following: an editor on a client; and an automation program via an application programming interface. The document is a network configuration file for at least one network device. Relevant portions of the unparsed document are provided for at least one of the following: display in a visual window; and use by the automation program. The first set of lines is based on at least one of the following: lines in the visual window; and lines determined by the automation program.

[0089] The data structures and code described in this specific embodiment are typically stored on a computer-readable storage medium, which can be any device or medium capable of storing code and / or data for use by a computer system. Computer-readable storage media include, but are not limited to, volatile memory, non-volatile memory, magnetic and optical storage devices such as disk drives, magnetic tapes, CDs (compressed optical discs), DVDs (digital versatile optical discs or digital video discs), or other media capable of storing computer-readable media now known or hereafter developed.

[0090] The methods and processes described in the Detailed Description section can be embodied in code and / or data that can be stored in a computer-readable storage medium as described above. When a computer system reads and executes the code and / or data stored on the computer-readable storage medium, the computer system executes the methods and processes embodied in data structures and code and stored within the computer-readable storage medium.

[0091] Furthermore, the methods and processes described above can be included in a hardware device or apparatus. For example, a hardware device or apparatus may include, but is not limited to, application-specific integrated circuit (ASIC) chips, field-programmable gate arrays (FPGAs), dedicated or shared processors that execute specific software programs or code segments at specific times, and other programmable logic devices now known or developed later. When the hardware device or apparatus is activated, the hardware module executes the methods and processes included therein.

[0092] The foregoing descriptions of various aspects are presented for illustrative and descriptive purposes only. These descriptions are not intended to be exhaustive or to limit the aspects described herein to the disclosed forms. Therefore, many modifications and variations will be apparent to those skilled in the art. Furthermore, the foregoing disclosure is not intended to limit the aspects described herein. The scope of the aspects described herein is defined by the appended claims.

Claims

1. A computer-implemented method, comprising: Receive a first request from the client, the first request being for a document that is parsed based on syntax; The document is parsed based on the syntax, resulting in an initial number of lines. Return the parsed initial number of rows to the client, thereby allowing the client to display the parsed initial number of rows in a visible window of the display; After successfully parsing the remaining lines of the document, store the fully parsed version of the document; In response to a scrolling action in the visual window, the relevant portion of the unparsed document associated with the first request is provided; In response to detecting the termination of the scrolling action, a second request is received, the second request being for the parsed rows corresponding to the first row set; as well as The system returns the corresponding parsed line from the fully parsed version, or parses the section of the document corresponding to the first set of lines to return the corresponding parsed line, thereby allowing the client to display the corresponding parsed line in the visual window.

2. The method according to claim 1, further comprising: Return the initial number of lines that have been parsed, while simultaneously parsing the remaining lines of the document concurrently in one or more stages; as well as After successfully parsing the rows for the corresponding stage, perform at least one of the following: Store the rows that have been successfully parsed for the corresponding stage; and Return the row that has been successfully parsed for the corresponding stage. This allows the client to perform at least one of the following: Receive the line that has been successfully parsed for the corresponding stage; and The stored rows for the corresponding stage have been successfully parsed.

3. The method according to claim 1, further comprising: In response to determining that the fully parsed version is stored or available, the corresponding parsed line from the fully parsed version is returned; as well as In response to determining that the fully parsed version is not stored or is unavailable, the section of the document corresponding to the first set of lines is parsed, and the parsed section is returned as the corresponding parsed line.

4. The method according to claim 1, Returning the parsed initial number of rows to the client also allows the client to: in response to receiving the parsed initial number of rows, store the parsed initial number of rows, wherein the initial number of rows is associated with the display's visual window. Returning the corresponding parsed line to the client also allows the client to: in response to receiving the corresponding parsed line, store the corresponding parsed line, and The method further includes returning the fully parsed version of the document to the client, thereby allowing the client to: store the fully parsed version of the document in response to receiving the fully parsed version of the document.

5. The method according to claim 1, further comprising: In response to determining that the scrolling action occurred during a predetermined time window, a third request is received, the third request being for the parsed row corresponding to the estimated viewport, wherein the estimated viewport is based on at least one of the following: The scrolling speed is based on the amount of scrolling action during the predetermined time window; as well as An estimate of the percentage of the document that has been scrolled through, the estimate being based on the amount of scrolling action during the predetermined time window.

6. The method according to claim 1, further comprising: Determine the first edit associated with the rows in the second set; The fourth request is received based on the first edit, the fourth request being for the updated parsed row corresponding to the second row set; The document is parsed based on the first edit; as well as Returning the updated parsed document, or the updated parsed row corresponding to the second set of rows, thereby allowing the client to perform at least one of the following actions in response to receiving the updated parsed document and the updated parsed row: Store the updated parsed document and the updated parsed lines; and The updated, parsed row is displayed in the visual window.

7. The method according to claim 1, further comprising: Multiple edits associated with multiple lines of the parsed document are identified, wherein the multiple edits are stored in a queue of the client until a condition is detected, thereby allowing the client to determine the order in which the edits are transmitted in response to the detection of the condition.

8. The method of claim 7, wherein detecting the condition comprises at least one of the following: Determine user activity delays exceeding a predetermined time period via the graphical user interface on the client; It has been detected that the user has generated a specific synchronization command via the graphical user interface; It was detected that, in addition to the multiple edits associated with the multiple lines, the user was editing a section of the document with more than a predetermined number of lines; as well as The length of the queue is determined to be greater than a predetermined size.

9. The method of claim 8, wherein the condition is based on at least one of the following: The time period since the latest user action was initiated via the graphical user interface; User actions initiated via the graphical user interface in a region of the document, the region being different from the region associated with a visual window that includes the plurality of lines; The size of the document; and The number of edits mentioned above.

10. The method according to claim 8, The editing includes at least one of the following: add operation, modify operation, and delete operation, and The order in which the edits are transmitted is determined based on at least one of the following: The order in which the user enters the multiple edits; The order of the multiple edits is based on the order in which the edits occur in the document; Multiple edits submitted as a single batch edit operation; All add actions as a single batch paste operation; and All deletion operations as a single batch deletion operation.

11. The method according to claim 1, further comprising: Determine the second edit associated with the rows in the third row set; The fifth request is received based on the second edit, the fifth request being for the updated parsed row corresponding to the third row set; Calculate the difference between a first state and a second state of the document, wherein the first state corresponds to the state of the document before one or more edits, and the second state corresponds to the state of the document after the one or more edits; Store the calculated differences; as well as The calculated difference is returned to the client, thereby allowing the client to respond upon receiving the calculated difference: The updated parsed rows are determined based on the third set of rows and the calculated differences; Store at least one of the calculated difference and the updated parsed row; as well as Displays the updated and parsed rows.

12. The method of claim 11, further comprising: Use the calculated difference to perform the subsequent undo operation.

13. The method according to claim 1, further comprising: Determine user activation via the referenced link through the graphical user interface on the client; A sixth request is received based on the user activation of the referenced link, the sixth request being directed to the resolved line mapped to the referenced link; In response to determining that the fully parsed version was not stored or is unavailable: The document is filtered and parsed by omitting lines with indentation greater than a predetermined number of spaces; Based on the filtering parsing, a lookup table is created that maps reference links to parsed rows; as well as Return the resolved line that was mapped to the referenced link; as well as In response to determining that the fully parsed version is stored or available: Search the lookup table previously created based on the fully parsed version; as well as Return the resolved line that was mapped to the referenced link; as well as This allows the client to display the resolved line mapped to the reference link in the visual window in response to receiving the resolved line mapped to the reference link.

14. The method according to claim 1, The first request is received via at least one of the following: The editor on the client; and Automation programs via application programming interfaces The document in question is a network configuration file for at least one network device. The relevant portion of the unparsed document is provided for at least one of the following: Displayed in the view window; and Used by the automated program, and The first set of rows is based on at least one of the following: The rows in the visual window; and The rows determined by the automation program.

15. A computer system comprising: processor; as well as A memory, coupled to the processor, stores instructions that, when executed by the processor, cause the processor to perform a method, the method comprising: Receive a first request from the client, the first request being for a document that is parsed based on syntax; The document is parsed based on the syntax, resulting in an initial number of lines. Return the parsed initial number of rows to the client, thereby allowing the client to display the parsed initial number of rows in a visible window of the display; After successfully parsing the remaining lines of the document, store the fully parsed version of the document; In response to a scrolling action in the visual window, the relevant portion of the unparsed document associated with the first request is provided; In response to detecting the termination of the scrolling action, a second request is received, the second request being for the parsed rows corresponding to the first row set; and The system returns the corresponding parsed line from the fully parsed version, or parses the section of the document corresponding to the first set of lines to return the corresponding parsed line, thereby allowing the client to display the corresponding parsed line in the visual window.

16. The computer system of claim 15, wherein the method further comprises: Return the initial number of lines that have been parsed, while simultaneously parsing the remaining lines of the document concurrently in one or more stages; After successfully parsing the rows for the corresponding stage, perform at least one of the following: Store the rows that have been successfully parsed for the corresponding stage; and Return the row that has been successfully parsed for the corresponding stage; and In response to determining that the fully parsed version is not stored or is unavailable, the section of the document corresponding to the first set of lines is parsed, and the parsed section is returned as the corresponding parsed line.

17. The computer system of claim 15, wherein the method further comprises: In response to determining that the scrolling action occurred during a predetermined time window, a third request is received, the third request being for the parsed row corresponding to the estimated viewport, wherein the estimated viewport is based on at least one of the following: The scrolling speed is based on the amount of scrolling action during the predetermined time window; as well as An estimate of the percentage of the document that has been scrolled through, the estimate being based on the amount of scrolling action during the predetermined time window.

18. The computer system of claim 15, wherein the method further comprises: Determine the first edit associated with the rows in the second set; The fourth request is received based on the first edit, the fourth request being for the updated parsed row corresponding to the second row set; The document is parsed based on the first edit; as well as Returning the updated parsed document, or the updated parsed row corresponding to the second set of rows, thereby allowing the client to perform at least one of the following actions in response to receiving the updated parsed document and the updated parsed row: Store the updated parsed document and the updated parsed lines; and The updated, parsed row is displayed in the visual window.

19. The computer system of claim 15, wherein the method further comprises: Determine the second edit associated with the rows in the third row set; The fifth request is received based on the second edit, the fifth request being for the updated parsed row corresponding to the third row set; Calculate the difference between a first state and a second state of the document, wherein the first state corresponds to the state of the document before one or more edits, and the second state corresponds to the state of the document after the one or more edits; Store the calculated differences; as well as The calculated difference is returned to the client, thereby allowing the client to respond upon receiving the calculated difference: The updated parsed rows are determined based on the differences calculated from the third set of rows; Store at least one of the calculated difference and the updated parsed row; as well as Displays the updated and parsed rows.

20. A non-transitory computer-readable storage medium storing instructions, said instructions causing the computer to perform a method when executed by the computer, said method comprising: The first request is received via an editor on the client, and the first request is for a document that is parsed based on syntax; The document is parsed based on the syntax, resulting in an initial number of lines. The system returns the initial number of parsed lines to the client while simultaneously parsing the remaining lines in the document, thereby allowing the client to display the initial number of parsed lines in a visible window of the display. After successfully parsing the remaining lines, store the fully parsed version of the document; In response to a scrolling action in the visual window, the relevant portion of the unparsed document associated with the first request is provided; In response to detecting the termination of the scrolling action, a second request is received, the second request being for the parsed rows corresponding to the first row set; as well as The system returns the corresponding parsed line from the fully parsed version, or parses the section of the document corresponding to the first set of lines to return the corresponding parsed line, thereby allowing the client to display the corresponding parsed line in the visual window.

Images