GB2362234A - Embedded Web interface - Google Patents

Abstract

A network device includes an embedded Web server that is capable of HTML page generation and is organised to generate separately the layout of a page and the variable information to be displayed on the page. The page layout is stored as a static file and the device includes a scripting engine for generating the variable information. The scripting engine generates a Javascript (RTM) program to set or update the displayed variable information. The page may constitute a mimic of the network device (as shown).

Description

EMBEDDED WEB INTERFACE

Field of the Invention

This invention relates to embedded Web interfaces and is particularly concerned with improving the usability and performance of such all interface, especially In a network device. Background to the Invention

It is known to provide, for example in a data-handling or processing device for use with a packet-based communication system, a Web server embedded in the device. The mail] functions performed include HTML generation, information presentation and form validation. In HTML generation, every page is generated on demand by a server script; In information presentation, when the user launches an operation, a server script is invoked which reads the data from the MIB (management information base) and integrates the It) In decoded data into a new HTNIL page. This page is then returned to the browser. In form validation, when the user submIts a form, its values are analysed by a server script, and if valid, the appropriate action is taken. This typically involves writing a series of values into MIB. If the form values are invalid, the server script must generate a message and g intearate it into a HTML. The page is then returned to the browser.

1 t> The reaction rate of current interfaces is highly dependent on the available bandwidth on the link between the browser and the server, as well as the reaction rate of the server.

When a HTML page is required, a Web server invokes the scripting engine which executes a script, which in turn generates an HTML page. The execution speed of the scripting, engine depends oil a number of factors, particularly.. the workload of tile embedded scripting engine (the number of concurrently executing scripts); the number of TCP connections beinserviced by the Web server, and the workload of the device. The scripting encrine task priority call become lowered when traffic levels are high.

Current Web interfaces are based upon older (and now obsolete) Web standards. Tile explosive growth Of tile World Wide Web was facilitated in part by rapid innovations in Web browser capabilities. In consequence, Web standards were ill-defined, non-existent or simply ignored. The browser developers' battle to gain market share has resulted in substantial differences between competing browsers and the inclusion of proprietary technoloales and incomplete or erroneous interpretation of standards. In addition, various browsers deviate considerably from the 'spirit' of HTN/IL, originally designed s a content markup language The World Wide Web consortium (W3C) is responsible for developing the standards relating to content markup, page display and user interaction. The evolution of HTML from version 1.0 to version 3.2 has seen the inclusion of a large number of tags and attributes relating to presentation of content (fonts, colours, etc) and positioning/dimensioning (widths, heights, alignment, etc). These additional tags and I ID In attributes are contrary to the 'spirit' of HTML since is was originally designed as a content markup language, primarily used to describe the meaning of the page elements (title, sections, subsections, paragraphs, etc) to the browser. The use of style- related tags and attributes to position and present page elements complicates the development, Interpretation and transmission of Web pages. In addition, this approach does not facilitate reuse of style specifications, thus increasing the cost of Web site maintenance.

In HTMEL 4.0, the World Wide Web consortium have decided to separate cleanly the topics of content markup and page presentation. To this end, they 'retired' all tags and 1: In elements relating to style and positioning of page elements, and have endorsed the use of Cascading Style Sheets as the primary mechanism for specifying such information.

I - The General State of the Art Earlier architecture falls Into two broad categories, Back-end architectures and front-end architectures. These are discussed below.

Back-end Architecture This type of architecture is older and more prevalent. In this architecture group. the bulk of the computational burden is handled by the back-end (i.e. the Web server embedded In the manaued device). The 'front-end' (i.e. the Web browser running on the user's PC) is ID used for display of HTML only. User interaction with the GUI is rudimentary and highly dependant on the network latency and the response rate of the embedded Web server. For example, if the GUI contains a Windows'95 Disk Explorer style tree of commands and the user clicks on a folder icon to expand/collapse a folder, the Web browser must send a messa-e over the netv,-ork to the embedded Web server. The server must then execute a script to regenerate the explorer tree HTML (expanded or collapsing the desired node), and to retransmit this over the network to the Web browser.

In 'back-end' architectures, almost all the HTML displayed on the browser is generated 1 dynamically by the embedded server. The generated HTML typically embeds device parameter values in a suitable visual metaphor (e.g. a dialog box with fields such as => n I I textboxes, textareas, option boxes, tick boxes, radio buttons, etc). Since the HTML dialog boxes contain a snapshot of the device parameters at the time of invocation, the browser must be instructed not to 'cache' the generated page. The generated page is not cachable because of the possibility of displaying 'stale' or old parameter values if retrieved from cache. Since generated pages are not cachable, each successive visit to the same dialoc, box necessitates sending a request to the device via the network, the execution of a script on the device's Web server, the generation of HTML output and the eventual retrieval and display of the generated HTML by the client system.

Back-end architectures are characterised by the following properties (a) The reaction rate of the GUI is highly dependent on the network latency since all user interaction with the GUI requires the transmission of messaores and requests to the device.

(b) The rate at \Yliicii the embedded seR,ei- can respond to requests fi0111 the Web browser is highlY, dependent on the computation resources of tile device (i.e. inernory and CPU), (c) All HTML output must be generated dyninically.

1 (d) Generated HTML cannot be cached.

Front-end Architectures Front-end architectures attempt to distribute the workload from the device onto the client system. Prior art in this area falls into two categories, characterised by Java applets and proprietary plugins respectively. In either case, the basic principle of operation involves the retrieval of a program module from the embedded device's file system onto the client system. The download module is then handled on the client system by a dedicated application which decodes and executes the instructions contained in the module.

In the case of a Java applet, the handler application is known as 'Java Virtual Machine'. In the case of a proprietary plugin, the handler application is known as a 'Plugin Player'.

When the browser loads the applet or plugin, it is then passed to the appropriate WM or Pluo]n Player for interpretation and execution. The browser is normally instructed to reserve a portion of its display area for use by the applet's visual output. Mouse events that occur in this specially reserved region of the screen are passed to the applet or plugin for handling. The applet or plugin can also communication with the device via a network connection.

The architecture is a front-end architecture that does not require a plugin player of Java 1 Virtual Machine and enjoys the benefits of fast response times and low memory footprint.

It is built upon a Dynamic HTML, which includes several interconnected technologies-, viz. HTkIL 4.0, CSS 1.0, Javascript, and Document Object Model.

In order to effect device management, the architectures uses the above technolo.-yes for a 1= 1-D purpose not originally intended by their inventors. It is important to note that tile architecture augments the capabilities of the aforementioned technolo.- Pes, particularly tile browser-device communication mechanism, based upon the user of 'hidden' frames and the encoding of device parameters in formatted Javascript function calls. In addition, the preferred implementation achieves performance gains over prior art by the use of caching and prefetching device parameters and separation of device parameters frorn the GUI display mechanism in dialoo boxes.

In the preferred architecture, the dialog boxes used to display device parailieters can be stored oil the device as static HTML. The architecture allows the device parameters to be dynamically inserted into the dialog box via the services of the client. This separation facilitates important optimizations in two areas:

(a) Since the dialog box HTML is static, it need only be retrieved once by the browser.

The HTML can be cached by the client and retrieved from cache to effect savings in network bandwidth and latency.

(b) The dynamic scripts which access the device parameters are considerably simpler since they are no longer required to integrate this information into a HTML page, and can therefore execute at a faster rate.

Summary of the Invention

The present invention in its preferred form includes tile reuse of style specifications to enable a reduction in HTML page size and required bandwidth. Style sheets also facilitate the definition of a central style repository, thus simplifying page development and maintenance times. The invention also preferably employs a browser's in-built scriptinal engine to facilitate the shifting of some of the workload from the device server onto the 30 browser. For example, forms can be validated on the browser before transmission or tile navicration tree can be manipulated (, expanded/collapsed) by the user without any server intervention. The invention also preferably includes tile separation of information and layout 0 e. presentation content). In particular it separates the generation of HTML page layout frorn the generation of the information displayed on the page. In most cases, tile ZN In, HTML pa,,e layout can be stored as a static file In the embedded file system - it need not be enerated by the server script. For example, a conformant device need only deliver the HTML content for its device minlic once (per session). The information required to display variable information, such as port and link status of the host device, may be performed by a separate function. This principle enables the interface to operate with substantially improved reaction rates, since the 'back-end' functions are considerably simpler because they are not required to format a complicated Web page.

The invention also preferably includes preloading. and background caching'. In particular it envisages the addition of intelligence to the 'front end' and enables the browser to preload ID information (e.g images, page content, device and stack status) in anticipation of user interaction. By building an information repository on the browser, the invention may make a substantial reduction in the amount of network traffic.

Brief Description of the Drawings

Fl,:)UFe I illustrates the main components of an embedded Web server. 20 Figures 2 to 21 illustrate the use of tags in HTML page generation.

I Figure 22 illustrates an HTML page including a Javascript program.

Figure 23 illustrates event tvpes in Javascript.

Fi,yure 24 illustrates a Javascript event-handling function.

1-n Fiaure 25 illustrates an HTML page relating HTML taers to DOM level 0 objects.

Figure 26 illustrates images and links in a document object model.

Figure 27 illustrate hierarchy of a document object model.

Figure 28 illustrates a hierarchy for an HTML document.

Figure 29 illustrates syntax for a document object model.

Figures 30 and 31 illustrate the user of <div> tags in a document.

c n Figure 32 illustrates a collection of layer objects. 10 Figure 3 33) illustrates accessing of Image objects.

Figure 34 illustrates the main components of a device including an embedded Web server.

Figure 35 illustrates a user's display interface.

Figure 36 illustrates HTML coding of a frame.

Figure 337 illustrates the relationship of frames to the user's display interface. 20 Figure 38 illustrates the content of various visible frames.

Figure -3g illustrates style classes relevant to FigUre.358.

1 Ficure 40 Illustrates an object constructor function.

Ficure 41 illustrates the location of objects within a frameset.

1:1 Figure 42 illustrates the fields and methods of a Toolbar Manager. 30 Figure 43 illustrates the relationship between the Toolbar Manager and Banner document objects.

Figure 44 illustrates a set of tab states.

Figure 45 illustrate the relationship between events, the methods of a Toolbar Manager and a tab object.

Figure 46 illustrates an Information Manauer.

1 Z:1 Figure 47 illustrates a Javascript array 10 Figure 48 illustrates the use of a 'for.... in' construct.

Fic,ure 49 illustrate the fields and methods of an Interface Mana-er.

Z Figure 50 illustrates frame interaction of an Interface Manager.

Figure 51 illustrate the fields and methods of a View Manager.

Figure 52 illustrates the interaction of Main display objects and Mimic objects.

Figure 53) illustrates a Main object.

Figure 54 illustrates contents of a Main object.

Figure 55 illustrates a compound object.

Figure 56 illustrates an updated object.

Figure 57 illustrates the fields and methods of a Mimic Manager. 30

Figure 58 illustrates a Mimic object.

-SI- Figure 59 illustrates a Mimic Manager and its related objects.

Figure 60 Illustrates a mimic of a network switch.

Figure 61 illustrates sub-miage components for the mimic shown in Figure 60.

1 -- Figure 62 illustrates the enclosure of a 'hotspot' within a hyperlink.

Figure 63 illustrates the format of a 'liref" attribute- Figure 64 illustrates various examples of the 'href attribute.

Figure 65 illustrates the format of a name' attribute.

Figure 66 illustrates the use of the name attribute.

Figure 67 illustrates the use of other attributes.

Figure 68 illustrates a six-layer mimic. 20 Figure 69 lists dimensions of layers in a mimic.

Figure 70 lists dimensions of a first layer of the mimic in Figure 68.

Figure 71 lists dimensions of a second layer of the mimic in Figure 68.

Figure 72 illustrates a modified version of a mimic.

Figure 73) lists the dimensions of a third layer of the mimic in Figure 68.

Figure 74 lists the irnages in a fourth layer of the mirnic in Figure 68.

W Figure 75 lists images in a fifth layer of the mimic in Figure 68.

Fi4ure 76 lists images in a sixth layer of the rninlic in Fii4ure 68.

Figure 77 illustrates the fields and methods of a Window Manager.

Figure 78 illustrates the interaction of a Window Mana!aer, a Dialog Box and an Interface Manaoer.

Figure 79 lists various launch methods.

Figure 80 illustrates methods of a Dialog Box.

Figure 8 1 illustrates the display of parameters of a Dialog Box. 15 Figure 82 illustrates the fields and methods of a Tree Manager.

Figure 83 illustrate the server architecture.

Figures 84 and 85 illustrate the format of a request to an Information Manager.

Figure 86 illustrates a code fi-aament.

Figure 87 illustrates a sequence of steps in obtaining information for display. 25 Figure 88 illustrates a display of parameters.

Figure 89 is a list of type attributes.

F]',,uFe 90 illustrates the encoding of a particular tao FiULIre 9 1 illustrates encoding, of various <option> elements.

Figure 92 illustrates response codes enclosed in Javascript.

Figure 93 illustrates response codes relevant to a dialog box5 Figure 94 Illustrates the results of submission of a form object.

Figure 95 illustrates an HTML display.

Detailed Description of a Preferred Example The World Wide Web is tile community of hypertext-enabled clients and servers on tile Internet. A 'Web Client' is typically a PC or Unix workstations with a TCP/IP stack and a Web browser. The purpose of a browser is to render and display HTML documents. A 15 'Web Server' delivers HTML documents, images and other media types over the Internet to the client via the hypertext transport protocol (HTTP). A web server consists of a number of components, namely (i) a HTTP module which listens for Web requests, (n) a file system containing static files (e.g. gif images) and 20 executable files-, and (m) a script interpreter which runs the executable files.

Figure I shows the major components of the server, comprising a protocol engine (TCP/IP), a file system which contains status files, e.g. gif images, an HTTP module 1:> In _n which listens for Web requests and a script engine which runs executable files. 25 A Web browser requests a resource by sending a request to the server. A resource is a page of HTML, an image, an executable file or some other media type. The server analyses the 'file extension' and performs one of two possible actions.

If the resource is a static file, the server retrieves the file from tile file system and returns it to the browser. If tile resource is a dynamic file (e.g. an executable file) the server retrieves the file and invokes the script interpreter. The script interpreter executes the file and sends the output of the program back to the browser.

The preferred form of the invention makes extensive use of Dynamic HTML in order to achieve its performance and usability objectives. Dynamic HTML is described in -HTML1 The Definitive Guide" by Chuck Musciano and Bill Kennedy, published O'Reilly & Associates Incorporated, Third Edition, August 1998. Dynamic HTML consists of a number of technologies. These are known as HTML 4.0; CSS (Cascading Style Sheets), JavaScript, and The Document Object Model. These component technologies are outlined briefly below HTML is a content markup language. Its proper use is to describe the various elements on a page - for example the document's title, abstract, section headings, paragraghs, images and so on. The page content is described to the browser using a set of 'tacrs' which 1-:1 In describe the meaning of the enclosed content. Every HTML tag consists of a 'name Z I followed by an optional list of tag 'attributes' all enclosed in matching brackets, as shown in Figure 2.

Tag are used to markup or describe the document's contents. Each tacr is typically applied 1:1 1 to a subset of the docurnent, known as the tag environment. Most tags mark their scope of applicability using a matching end-tag marker, which is composed of a '/' character followed by the tao name, enclosed in matching brackets, as shown in Figure 33.

For example, the <title> tag is used to describe the document's title to the browser as shown in Figure 4.

The tag 'attributes' modify the behaviour and interpretation of the taCr and its contents. In its purest form HTML describes the page content to the browser, which then displays each element in an appropriate style, e.g. a title is usually displayed using large, bold font while an emphasised itern may be italicised. The ID and CLASS attributes are used extensively in HTML 4.0 to apply style rules to general classes or specific instances of tag, environments. Both attributes are optional. A tag environment can be a member of one class at most If an ID is applied to tag, it must be unique in that document. These attributes will be discussed in more detail.

The orlainal definition of HTML has been extended to include tas and atrributes in order to give the user more direct control over the layout and presentation of the page elements.

This trend continued up to HTML 33.2 resulting in an overly complex and inelegant standard. Pace designers typically used the <frame> element to partition the browser window into a number of frames and the <table> element to position page elements within each frame. Other style-related information - such as the alignment of a block of text or the size, colour and font family to be used - was specified usincr an extensive set of taa attributes. Figure 5 shows a typical example of HTML 3.2. The intention of this fragment is to position the word 'Nightingale' near the browser's right-hand side, and to format the text in srnall bold green arial on a red background.

1 1 One of the major disadvantages of HTMI- 33-2 is that the user cannot reuse style specifications. If the page designed required two or more segments as defined above, the

Z same posItIoning and display information must be repeated each time. This complicates the task of designing Web pages and increases the cost of page maintenance. It should be noted that the W33C have 'retired' all tags and attributes associated with page presentation.

The recommended method of specifying such information is through Cascading Style Sheets.

1ATMI 4.0 uses the <div> and <span> tags as generic HTML containers. The <span> tag t) 1 - 1 is used to hold inline content, while the <div> tag is used for block level content. These two taos are used primarily to define regions of the document onto which a presentation style will be applied.

A generic HTN/LL page consists of a document 'head' and a document 'body'. The document head contains information about the document, while the document body contains the content of the document itself The document head may be declared explicitly using the <body> tag or may be inferred by the browser if absent. If declared explicitly, the document head must precede the body.

All HTML tags must obey a containment model. The HTMI- containment niodel is a set of rules governing if and how one HTML tag may contain another. Both the <head> and 1 n <body> are contained within the <htiiii> tag which cannot be contained in ally other ta.

The relationship between the <litiiil>, <head> and <body> tags is illustrated ill Figure 6.

The approved and corrected inethod for specifyin., style-related issues (e.,-.,,. fonts, colours, dimensions, etc) is through the use of Cascading Style Sheets (CSS) which facilitate the declaration of a central style repository as well as simplifying the content of the HTML In pages. When the Web pages are resident on a device, CSS can effect a good reduction ill 1 -- the total amount of flash space required since it facilitates reuse of style specifications.

A presentation style can be applied to a document in a number of ways. CSS 1.0 (Issued by W3W in December 1996) defined the following style sheet types: 'Linked'. 'Imported'.

Z 'Document-level', and 'Inlliie'.

Linked and Imported style sheets are known as external style sheets and they reside in a separate file from the Web page. Imported style sheets are not yet implemented by a 1 version 4' browsers and will riot be discussed here. 20 The style specifications residing in a linked style sheet are applied to a 1ATMI document using the Aink> tag. The Aink> ta. gives information to the browser concerning the type and location of the style sheet. If present, the Aink> tag should appear within the <head> tac as shown in Figure 7.

The 'href' attribute is mandatory. The value of the href attribute can be either full or partial URL. Note that the type attribute specifies that the external style sheet conforms to the CSS standard. Tills attribute allows for the possibility of other types of style sheets in the future.

A linked style sheet call be referenced by more than one Web document. thus facilitatin') a high level or reuse of its style specifications. Linked style sheets are typically used to - is- manage the 'look & feel' of a corporate Web site. since they allow the central declaration of a style repository and chances made to the style sheet are automatically inherited by all documents linked to the repository.

A document level (or embedded) style sheet is a set of style specifications that are declared internally in a document and which can only be applied to that document. The style specifications in a document level style sheet can be applied and reused only within the scope of the document. The embedded style sheet is declared in the document's head as shown in Figure 8.

The style specifications to be applied to the document consist of a number of style rules.

Style rules can be divided into the following categories: (1) tag rules which apply to every 1 1 1 instance of the specified ta-g; (11) class rules which apply to every member of the style class. (111) subclass rules which apply to a selected subset of a specified tag., and instance rules which apply only to the unique tag with the specified ID.

Style rules are declared using a selector (which identifies the rule category) followed by 1 - one or more style declarations.. The general syntax of a style rule is as shown in Figure 9.

1 The selector can specify a tag family, a general class of tags, a subclass of a specific ta. or a specific instance of a tac, within the document. For a 'ta.

rule'; the selector the name of the tau. For a 'class rule', the selector is the class narne preceded by "." For 'subclass ruies, the selector is the ta(y name followed by -.- Followed by the class name. For an instance rule', the selector is the tag's ID preceded by "#". An example of each of these selectors is illustrated in Figure 10.

It should be noted that HTNfl- is case insensitive- In teri-ns of the above style rules, the tags shown in Figure 10 will inherit the same style rules.

The style declaration consists of a style property name followed by a style property value as shown in Figure 11.

CSS 1,0 allows the user to declare style rules for font properties such as faintly, style, variant, wej,)iit, size, colour and background properities such as colour, background colour, pattern, position, text properties such as word spacing, letter spacing, text 1 1 decoration, alignment, indentation, colour. box properties such as margin, padding border, width, height, position, and display properties such as display style.

Figure 12 shows how to apply a tao, rules to the <p> ta. to specify that the enclosed text is displayed using 10 point Arial justified text.

In this example every instance of the <p> tag in the document 'inherits' the style rules applied to this tag via the style sheet. The style sheet therefore simplifies the structure of the document body since the style information is maintained in the style sheet. Note also the style sheet inheritance mechanism facilitates a high level of style rule reuse.

Style rules can also be applied to a general class of tags. Figure 1-33 is an example of how to specify a class rule to select red as the foreground colour.

In this case every tag whose 'class' attribute matches 'important' will be rendered using 1 red as the foreground colour e.g. <p class=] mportant>, h2 class=important> etc.

The application of style properties can be restricted to a subclass of a tag by combining the 1 tag name with the class name. Figure 14 shows how to specify a subclass rule.

1 1 In this case, every <div> ta. whose 'class' attribute matches 'menu' will be rendered using leftaligned 12 point text.

C) Z> An 'instance' rule applies to a single tag. An instance rule applies to the tag whose 'ID' attribute matches the selector. Figure 15 shows how to apply an instance rule to a single paragraph.

If the document contains a tag whose ID attributes matches the above selector, then the above rules will be applied to the selected tag's contents and none other.

W A style sheet call be attached directly to a tag ill which case it is known as all inline style sheet. Unlike document level and linked style sheets, all inline style sheet cannot be reused. Inline style sheets call be used to override the style rules specified in a linked or document level style sheet. An inline style sheet is declared using the tag'sstyle attribute shown in Figure 16.

Figure 17 illustrates the declaration of an inline style sheet.

Inline style sheets should be avoided since the 'clutter' the HTML content with style information and since these style sheets can only be applied to the selected tag, they lead to bigger, less maintainable documents.

1 c> Style rules can be combined and grouped. The style rules associated with a tag, class, subclass or individual can be declared in several stages. In such cases, the style rules accumulate. If more than one rule is applied to a style property the last rule overrides all previous rules. For example the declarations shown in Figure 18 are equivalent to the declarations shown ill Figure 19, wherein the 'font-family' style rule for 'courier' has been overridden.

Style rules may be grouped in order to minimize repetition and thus facilitate ease of maintenance and space conversation. Grouping is achieved by using a comma. as the selector separator, as shown in Figure 20, with commas between 'selector V, 'selector 2, 1 - - and 'selector_-')'. A specific example of selectors, namely V, 'HP and 'TABLE' and the declaration of 'font-family' (arial) is shown in Figure 2 1.

In the above example, the font-family rule is applied to all three selectors without having to make three separate declarations, one for each tag.

The HTML 4.0 specification permits the use of 'client side scripting' to add behaviour and interactivity to be added to Web pages. HTML and CSS are used to specify the 'Initial state' of a page - Le. the page's content and presentation when the browser first renders it.

Client-side scripting determines how the page, particularly its presentation and content, changes over time in response to user action. To this end, the HTML 4.0 specification identifies a set of events (e.g. clicking a button, loading a document, mousinor over an image, etc etc) and allows an event handling function to be invoked as part of an element's behaviour. Javascript originally developed by Netscape has emerged as the de-facto standard in this area, althou-h other scripting languages are permitted, notably Microsoft's VBScript Javascript is described for example in Javascrlpt The Definitive Guide by David Flanagan, published by O'Reilly & Associates Incorporated, Third Edition, Julie 1998.

Javascript is an interpreted, event-driven object-oriented language. A Javascript program is a collection of event handling functions, and can either reside in a separate file or be embedded within the document. If the Javascript program is external, it can be reused by Z.

many documents. A Javascript program normally resides in the document's head and is 1 declared as shown for example in Figure 22. The syntax of the core Javascript language Is similar to Java in the sense that a Javascript program uses common programming declaration and control constructs, such as the function 'if-else' and 'for' loops. Unlike Java, Javascript is a loosely typed language, which means that variables are declared = n I - without specifying their type, Javascript's object-oriented facilities differ frorn Java's, 1 particularly the inheritance mechanism. Javascript is an event-driven language. This means that a Javascript function is invoked in response to an 'event'. An 'event' is typically initiated by the user. Figure 23 lists some of the event types recognised by a Javascript proorram, the triggering of each event and a description of each event type.

In order to invoke a Javascript event-handling function, the function must be associated I with the event. This can be done by setting the tag's event handling attribute to 'point' to I the desired function. Figure 24 illustrates how to associate a user- defined function called highlight ()' with an image taas 'onmouseover' event. When the user moves the mouse D over the linage region, an 'onmouseover' event is generated. The browser's event handling mechanism causes the Javascript function 'highlight to be invoked.

At present, Javascript is the only universally acknowledged scripting language for the Web, supported by Netscape, Microsoft and others (Opera, for example). The syntax of the language is defined by ECMAScript Language Specification, European Computer

Manufacturers Association. ECMA-262, 2 nd Edition, August 1998. For the version 4 browsers, there is almost total conformance to the core language standard.

I I When a HTML document is loaded into a version 4 browser, the browser generates a representation of the page and some of its contents. This representation is known as tile document object model'. The browser presents an interface model and allows a Javascript program to access the representation. The first such document object model was proposed by Netscape in their version 2.0 browser and was subsequently adopted by Microsoft in version 33.0 of Internet Explorer. This preliminary model presented an interface to a small subset of the page's contents, notably the collection of hyperlinks and images on the pace.

This model, known as the DOM Level 0, was endorsed by the W3C who subsequently extended to concept to develop a more Comprehensive set of objects and functionality.

This model is known as the DOM Level I and was issued as a recommendation in October 1998. See for example Document Object Model (DOM) Level 1 Specification. World

Wide Web Consortium. REC-DOM-Level- 1- 199800 1. October 1998.

The DOM Level 0 specification defines a subset of HTML tags which, when rendered by the browser, will be accessible to a Javascript program. In general, tags belonging to the DOM Level 0 subset will result in the generation of an object representation of the tag This object has a set Of predefined methods that can be invoked by a Javascript program and a set of attributes which can be accessed by a script. The attributes may be read only, or read/write. In DOM Level 0, collections of similar objects are grouped in arrays. Level 0 groups include frames, images and hyperlinks.

I The example in Figure 25 shows how HTML tags are related to DOM Level 0 objects.

When rendered the browser generates images and links as shown for example in Figure I - 26. In the example shown in Figure 26 the DOM representation of the document contains two object collections - the images array, i.e. images [01 and images [1] and the links ID 1.) array, i.e. links [0) and links [0]. Each object collection consists of an array of elements.

The elements in the array contain reference to other objects. In the case of the images collection there are two elements in the array, one for each image in the document. Each image object contains a set of fields that can be inspected and/or changed by a Javascript program. For example, accessing images[ 1].width would result in 25, while links[0].href would evaluate the string 'littp://www.-')coin.coni".

In terms of object-oriented nomenclature, each DOM object has three essential properties, namely 'Identify', the name of the object - e.g. images[l]- 'state', the object's fields - e.g- Images[ 1].width,- and 'behaviour', - the object's methods.

Level 0 objects are organised in a well-defined hierarchy. At the top of the hierarchy is the window object. The window object may contain a single HTML document OF It may contain a frarneset HTML document. In the latter case, the 'window' object will contain a 'frames' collection, the elements of which will contain a 'document' object. This hierarchy is illustrated in Figure 27.

The Level I Dom exposes the complete content of the document - its text,, HTML elements and the attribute names and values of those elements. The document is represented as a tree of objects, where each object represents either a string of text or a HTML tag and its attributes. The root node of the tree is the <html> tag. The root node has two child nodes representing the document head and body. Each of these child nodes ma I y have further child nodes - the document's <title> is a child of the head, for example. The Level I DOM provides an API to navigate and traverse the tree of nodes by means of 0 object methods which return the node's parent and child nodes. The Level I DOM also provides methods to inspect and modify the attributes of existing nodes as well as Z functions to remove and insert nodes. The hierarchy is shown in Figure 28. The structure ID of the Level I tree depends on the nature of the HTML document. Figure 28 shows the tree structure for a hypothetical document.

Currently available browsers implement their own proprietary implementation of tile Document Object N/lodel, and differ in their adherence to and implementation of tile various W3)C and other standards, notably ECMA 262, the Javascript standard.

The implementation of the DOM is the largest area of discrepancy between the version 4 1 browsers. Microsoft's implementation is by far the most comprehensive in the sense that almost all tags generate a scriptable object representation in the DOM. Netscape offer a far smaller set of objects with significantly fewer fields and methods per object.

Netscape's orlginal implementation of Dynamic HTML was based on the use of tile <layer> tag which was proposed to and later rejected by the World Wide Web I Consortium. A document layer is a generic container that can be used to hold HTML I content - any tag that can be contained within a <body> tag, including other layers.

I - - In Netscape's implementation, document layers can be dynamically positioned on the Screen, they can be superimposed with a well defined stacking order and their colour and visibility call be dynamically altered by scripting The <layer> tag is not part of the HTML 4.0 standard and implementation should not use this tag. However, it is possible to generate a layer object without using the <layer> tag The recommended method of generating a layer object is to use a <dlv> instead. There is one important restriction. the style class associated with the <div> must declare a style rule of 'positiomabsolute'. When Netscape version 4 renders a <div> with the above style rule it generates an element in the layers collection. If a <dlv> is declared without the position absolute' style rule, the contents are rendered normally, but no object is generated. The position property can be applied by any means of applying style properties to a tagg via a tag rule, a subclass rule or an instance rule. The style rule can reside in an external or document level style sheet or can be applied as an inline style.

Due to the differences in tile object representation between the version 4 browsers, document objects resulting from a HTML specification are accessed in a number of ways.

If the object is a member of a small subset of tags that map into the DOM level 0 set of ZN objects, then in general, the object is accessed identically in both browsers. Tills includes the window object, the frames collection, the document object, the document images, links anchors and forms. In either case, an object that is part of the level 0 collection Is accessed via the syntax shown in Figure 29, wherein the 'object' is images [2] and the 'property' is width.

With the exception of a positioned <div> and the object collections, none of Netscape's taus cause DOM objects to be generated. When a positioned <div> is present in the docunient, a laver's object is generated in Netscape, and a general object is generated in Microsoft's Internet Explorer. Tills object is accessed in two different ways, depending oil the browser. In Netscape, the object is accessed via the layer's object, while in Microsoft Internet Explorer, the object is found in the 'document.all' object. Figure 30 illustrates a document containing a positioned <dlv> whose ID attribute is set to ID=objectl.

A further complication arises if a positioned <div> contains other positioned <div> elements. Microsoft Internet Explorer allows the user to access every object, regardless of containment, in a flat topological space. It does this by providing references to every object via the document.all object. In Netscape Navigator the object space is hierarchical.

Essentially, each layer object is a separate document, which may contain collections (such as links and images) as well as other layers. In order to access the methods or properties of all object collection, it is necessary to know its location in the containment hierarchy.

Figure 31 illustrates a document including, <div> tags.

If the <div> tags have the 'position: ab solute' rule applied, the Netscape Navigator browser will generate a collection of layer objects. Inspection of the document will reveal the 'objects' shown in Figure 32.

In Netscape, each positioned <div> generates an entry in the enclosing document's layers I I collection. A layer object behaves like a document object. In the above example, the outer docurnent has an Images collection with one entry - -3com.gif". Its layers object contains Z) a nonnull entry - for the 'first' layer. This layer object contains one entry in its Images collection ("cisco.-If') and one entry in its layers collection ("second"). The second layer object contains just one object - the image object for the "bay.gif' iniage. In Microsoft Internet Explorer, all three images are available in outer document's images array.

Accessing an element of an object collection is straightforward in Microsoft Internet Explorer - the syntax is not affected by object nesting. In Netscape, the object must be prefixed by its path through the containment hierarchy. Referring to the previous example, the three image objects in the document are accessed as shown in Figure 33) I The major difference between Internet Explorer and Netscape Navigator is in the I browser's reflow ability. A number of style properties can be dynamically updated by scripting. In certain cases, the style changes might cause the dimensions of the object to I I =1 change. Microsoft Internet Explorer supports dynamic (or incremental) reflow, which means that after the change it effected, the object and all subsequent content is rerendered in situ by the browser. Netscape Navigator does not currently support this ability To illustrate this, consider the display-style property. A HTNfL element is either a block level element - it has a line break above and below it or it is an Infine element - the element's contents are part of the flow of the document. When a tag is rendered, it inherits a default value for the display-style property (either block or none). A value of none results in no rendered content - the browser effectively ignores the tag. If a Javascript program alters the value of the display-style property from its initial default value to none, then in Internet Explorer, the element is removed from the display an d the remainder of the content is rerendered and reformatted. In Netscape Navigator, nothing happens.

The Architecture of the Present Invention The present example of the invention is a Web-based client./server architecture aimed at effecting device and stack management for memory and processor bound network devices.

A conformant device contains an embedded Web Server. The Web server listens for and validates HTTP requests on an appropriate port of the device. An HTTP request specifies a server-resident resource which resides in the file system of the device shown in Figure 34. A VFS (Virtual File System) Manager.3340 retrieves the requested file from the file system 341. If the file is static, It is passed to the HTTP module '342 and is returned to the -, engine 343. This contai requester. If the file is dynainic it is transferred to the scriptInS DI I Ills a script interpreter which executes the commands contained in the dynarnic file. script corninands perform computational tasks and generate an output stream. Script commands cari also access the SNMP agent 344. A SNMP agent Implements the SNMP protocol commands GET, SET etc. These commands are used to read and write values to the device's MIB databases 345. Device MIB databases are used to store the device's operational parameters - e.g. its name, contact & location, the number of Ethernet packets received on a particular port, etc. The device will normally include a TCP/IP protocol stack 346.

The device's file system 341 contains the client and server components. The client components consist of a number of file types. These are image files denoted ".gif', HTN/11- docurnents denoted -.htmF, Javascript program libraries denoted ". 's" and CSS specifications denoted -.css".

Froin the point of view of the embedded Web server, these files are static - if requested, they are retrieved from the file system, then sent to the HTTP module and finally sent back to the requesting agent.

Z) 1-> The server components fall into two broad categories: data generation scripts denoted rhtm" and data processing scripts similarly denoted "Atm".

Both file types are dynamic from the point of view of the embedded Web server. If a file of this type is requested, it is retrieved from the file system and transferred to the scripting engine. The scripting engine then executes the stream of instructions contained within the file and sends the script's output back to the VFS manager, whence it is then sent to the requesting agent via the HTTP module.

la When the user directs his Web browser at a device or stack, the embedded Web server sends the requesting Web client all of the resources (HTNfL, CSS, JS and images) required to build the client interface oil the browser's display area.

-25 When the Web client loads the client files, it renders the displayable content and executes the dynamic content. The client effects device and stack management by communicating I:) - ZN with the server components resident on the device. In particular the client reads the device's parameter values by requesting a data generation script and sets new values for these parameters by requestinc, a data processing script.

Client Components The section describes the major components of the client side architecture. These components are defined by a set of HTML files, images, CSS style sheets and Javascript programs that reside in the device's file system. When the user directs the browser at the device or stack, these files are transferred to the browser, whereupon they are rendered and displayed or executed as appropriate.

The user inter-face is designed to be displayed on an 800600 pixel PC screen with a C colour depth of 8 bits. The display is divided in a number of separate sections.

The banner' is located at the top of the display and its present corporate branding information. The banner does not contain any 'clickable' regions The 'toolbar' contains a number of tabs, which are used to switch between major views, The current Nightingale specification contains three such views- The 'Device View' contains operations to enable the user to configure and monitor the sta& The 'Web Console' is an interface to the stack's CLI-I and 'Help' hyperlinks to the help and documentation for the stack.

Each view has an associated navigation tree and display area. The purpose of the tree is to present a coherent view of the functionality available in the chosen view. The main display is used to present important information to the user, such as the system overview or a device mimic. Figure 35 shows an example of the display.

The user interface is divided into a set of named frames as follows (a) Banner: this contains the Nightingale banner and the toolbar.

(b) Tree: this contains the navigation tree appropriate to the selected view. 5 (c) Main: this contains irriportant information relevant to the selected view.

(d) ForniReply. this Is an invisible frame used to receive a response after form submission.

(c) PollReply: this is an invisible frame used to receive polled data from the stack.

Figure 336 shows an example of HTML code defining the dimensions and positions of a frame. Such a frame is preferably made invisible by giving it zero height (or width). Tile C) t In frame is not resizable by the user and is displayed without borders.

Note that 'Tree', 'Main' and the two hidden frames initially contain a null document (null.htnil).

Figure 37 relates the above named frames to the user interface.

The visible frames form the user interface. Each frame contains a set of document objects.

Figure 38 outlines the contents of each of these frames.

The style class referenced in Figure 38 are defined in the embedded style sheet belongille, Z) to each frame. For completeness, the style classes are listed in Figure 39.

Note that the above style classes set the visibility of the tabs, tree and main display areas to hidden. When the startup procedure has completed (Including the attachment of event -Y handlers onto an), click-able areas), these regions are then set to visible.

The client functionality is divided into the following functional elements.

1 The Toolbar Manager is an 'object' which manages the user's Interaction with the tabs. A tab is highlighted when the user rolls the mouse-driven pointer or its equivalent over the tab region. Clicking a tab activates the selected view while deactivating tile previously selected view. Each view has an associated navigation tree and main display. When a view is activated, its tree and main display are made visible. The Toolbar Manager must also remember the 'state' of a view on exit so that the prior state can be restored oil return.

The Tree Manager is a module which is responsible for building Explorerstyle trees using 1 1 subtrees obtained from each device in the stack. The tree is assembled and interactive behaviours are then added to enable the user to expand/collapse folders, show system or device information and to invoke operations.

The View Manacer is a component which receives a message from the Tree Mailauer and displays information appropriate to the selected view in the main display area.

The Mimic Manager is responsible for displaying a device mimic, polling the device for its link and port states, and handling the user interaction with the mimic (e.g. adding the behaviours that enable commands to be invoked from the mimic).

The Window Manager is operative when a device or stack command is issued and a new window is opened containing a form or'Wizard'. The Window Manager is responsible for managing the interface between the dialog box and the browser window. The Window Manager includes facilities to open and close a window and to prevent the user from launching multiple commands at the same time.

The Information Manager is the central repository of all information required over the duration of an interaction session with a stack or device. The Information Manager is used to store user information, device information and HTML required for device/stack operations.

The Interface Manager is an 'object' which manages the interface between the device/stack and the Nightingale client. The Interface Manager provides facilities to 1 request the execution of a script on the device and to retrieve a resource (e.-. a HTML file) from the device The Dialou Box is a means by which the device's parameters are displayed in a separate Z - window which is a child of the client's parent window. The dialog box typically contains forms which display the device"s current parameter settin-p as well as offering a means of 1:1 1:1 setting alternative values for the parameters.

The client components preferably are implemented in Javascript and are executed by tile browser. For each Manaaer above, there is a Javascript object constructor function. The constructor function is narned identically to the Manager objects above, without ally embedded spaces. On startup, a single instance of the object class is generated. The class instances is given the same name as the class constructor function, with the exception that the first letter is not capitalized. Ali example is shown in Figure 40.

The location of the objects within the frameset is shown in Figure 41.

The Dialog Box is as noted above a child window of the client. A Dialog Box is generated when the user clicks on a command icon in the tree. Only one Dialog Box can be open at any time. A Dialog Box contains a set of 'buttons' for controlling the window and usually contains an 'OK' and a 'Cancel' button. The Dialog Box is dismissed by clicking either of these buttons, or by clicking the 'x' at the top right corner of the window. The Dialog Box can make extensive use of the services provided by the client Manager objects, particularly for the display and submission of device parameters.

The Toolbar Manager is responsible for trapping the user's interaction with the tabs in the toolbar and for switching between views. The Toolbar Manager makes no assumption about the number, position, location or dimensions of the tabs. The fields and methods of the Toolbar Mana-er are shown in Figure 42 The Toolbar Mana(yer interacts with the tab objects that reside in the Banner frarne. There is one tab object per view, and each tab object contains a tab image, which corresponds to the name of the view. The Banner object and the Tabspacer object (which is used to fill out the unused portion of the toolbar) do riot have the facility to trap user events and the Toolbar Manauer does riot interact with either object. The relationship between the Toolbar Manager and the Banner document objects is shown in Figure 433.

It is assumed that the tab object contains an image whose name conforms to the followillG, C> scheme:

Iiiia(yeNanie-inia,,eState.,,f 10 where 'ImageName' is an alphabetical identifier (with no embedded ---) providing a brief description of the image and 'ImageState' is a positive integer. For example---dv-0.gif'. "lie-5.c,lf' or "webconsole-8.clf' are valid tab image names.

Tabs respond to three user generated event types, namely 'mouse over', 'mouse out' and Z mouse click'. Each event has an associated image. A tab is either unselected, selected or is being moused over. The imageState literals are associated with these tab states as shown in Fiaure 44.

The Toolbar Manager provides a set of services to handle the 'mouse over', 'mouse out' and 'mouse click' events- These event handlers are applied to a suitable tab object using a Toolbar Manager method which dynamically applies the handlers to the object (addTabBehaviour). The method 'tabObject^ is used to provide 'addTabBehav lour' with a reference to the tab object. The event handlers for the mouseover and mouseout events (tabMouseover, tabMouseout) dynamically alter the tab image in reaction to the event.

Z.

The method 'tablmage' is used by the event handlers to obtain a reference to the tab's C=.

associated image. The tab click handler (tabClick) sets the tab image to the lilglillc,hted/actlve state and invokes a method of the Tree Manager which causes the tree associated with the selected view to be displayed. The relationship between the events, tile Toolbar Manager's methods and the tab object is shown in Figure 45.

1 1 The Toolbar Manac "D er is also responsible for initializing the client, i.e. performing the following steps retrieving stack and unit information, loading the Tree and Main Frarnesl initializino the Information Manaaer- initializing the Tree Manaoer- initializinu the Tree Z -1, 1:1 Manager-, initializing the Mirnic Manager, attaching the event handlers onto the tabs, simulatin- a click on the first tab.

The method 'Initialize' effects the initialization of the client. This method is invoked as the 'onload' handler of the Banner firame. The fields 'task' and 'timer' are used by initialize' as part of its scheduling mechanism.

On startup, 'toolbarManager. initialize' invokes 'addTabBehaviour' to attach event handlin- ffinctions on to each tab object.

The Information Manager is the central repository of data on the client. Device parameters can be retrieved from the managed device and stored in the Information Manager. The Information Manager facilitates reductions inparameter lookup time and network bandwidth by mirroring part of the device's parameter set. This information is categorized in six main divisions as outlined in Figure 46.

The fields shown in Figure 46 are compound objects (with the exception of views). They are:

browser' which contains parameters relating to the browser e.g. the browser narne server' which contains information relating to the structure of the server's directories and file types, views' which indicates the number of views.

user' which provides user information such as the user's name-, stack' which provides general stack information such as the name, contact, location and IP addressl and 1 unit which provides an array of unit information such as name, device type, software/hardware version numbers etc.

The methods of the Information Maria-ger are 'update' which is used to update a field of set of fields, createUnit' which initializes a unit description object, and addUnit' which adds a new unit to the unit array.

Tile unit field is implemented using a Javascript Array object. Unlike arrays implemented in C or Java, Javascript's arrays are associative and sparse. The sparsity of Javascript's arrays is of benefit when modelling a stack of devices since there may be 'gaps' in the unit indices. In general, if unit i exists in the stack, then its device parameters are stored and mirrored in the array element Info rmat lonManager. unit [1].

The lenath of a Javascript array is the index of its last element, plus 1, regardless of Z) In whether the entries from 0 up to the last element are defined or not. The only exception is an uninitialized array which has len-th 0 by default. These features are illustrated in tile code fraument shown in Figure 47.

A Javascript array can be inspected without explicit knowledge of the gaps in the array.

I The 'for..in' construct is used to 'examine' the nonnull elements of a sparse array. Tile example in Figure 48 illustrates the use of the lor.. in' construct to compute the numeric sum of the elements of a sparse array.

The Interface Manager provides the communication interface to the stack or device. The I Interface manager makes extensive use of the Nightingale client's two 'hidden' frames in Z:- 1 1) order to achieve background communication with the device or stack. The Interface

Manager also operates on Nightingale's visible frames, particularly during the initialization phase. The fields and methods of the Interface Manager are shown in Figure

49 and the frame interaction is shown in Figure 50.

1:1 The fields 'busy' and 'tiiner' are used for signalling and lockin(gy purposes. The methods of the Interface Manager are associated with requesting a device resource (get) and handling Z -- In -:1 tile response from tile device when the resource has been delivered (handleReply), The method 'I riterfaceinanager. (yet is used to request a resource from tile device. Tile primary use of this niethod is to retrieve HTML content, which is loaded into a specified frame. This method Could also be used to retrieve other content types, such as Image files etc. Tile Interface Manager is independent of the number and names of the client's firarnes.

When a resource is requested, get alters the location object of the specified frame. This causes the browser to load a new document into the frarne. This document typically (although not necessarily) contains a Javascript program. The method 'handleReply' is used to signal the conipletion of tile transaction, together with any error or status messages. As part of the response function, the communication channel with the device is released by invoking the clear method.

There is one important restriction on the use of the 'get' method. The 'get' method uses a predefined method of the location object called replace. Invoking 'get' in turn invokes location. replace' which specifies a new URL for the specified frame. At present, both Netscape Navigator and Internet Explorer execute the browser application using a single thread of control. A call to 'location- replace' is not effected until after the current thread has expired. In general, each event executes in a thread. A call to 'get' will not block, but => =I the requested resource will not be available for processing within the same thread of I control. Therefore, it is not possible to make more than one call to 'geC in any one thread of control. This restriction imposes additional requirements on the server components.

The View Manager controls the display of information in the main display area. Its methods and fields are shown in Figure 5 1.

The View Manager interacts with the document objects in the Main frame, namely the I Main display objects and the Mimic objects, as shown in Figure 52.

The View Manager controls the display area by managing the visibility property of the Main document objects using the display method. The field selected records which Main

1 object is visible. Tile visibility state of the Mimic document objects is maintained by tile Mimic Manaaer. The field 'R-HS' is used to record which document object type is visible in the main display area - for example a Main object as shown in Figure 53).

The contents of the Main objects depend oil the information to be displayed for tile associated view. Ill a first phase, the contents are as shown in Figure 54. Ill tills Figure MainO is a compound object consisting of two child objects called 'stackinformation' and 1 stacksummary', as shown ill Figure 55.

The object 'stackinformation' contains a table showing general stack information, such as 1 - name, contact, location, up tli-ne etc. The 'stacksurnmary' object contains a table showinC, W a list of all units ill the stack, their names, device types, software version, hardware version etc. The methods 'updateStackSummary' and 'updateStackInfornlation' are used to generate and refresh these tables. These methods read all device and stack related parameters from the Information Manager. These methods are invoked during the client initialization phase and also immediately after the user has issued a command to change any of the afore ment to tied parameters. The updating of MainO is shown ill Figure 56.

The Mimic Manager is responsible for generating the device mimic, polling the device for 1:1 1=) In information, displaying on the device mimic. It is also responsible for the management of the table of device information and the notepad associated with each device mimic. The fields and methods of the Mirnic Manaaer are shown in Figure 57.

The Mimic Manager interacts with the Mimic document objects, the Information Manager and the Interface Manager. The Mimic document objects are compound objects, each containing three child objects - the unit mimic, the unit summary and the unit notepad, as shown in Figure 58.

The method 'ToolbarManajer.itiltialize' retrieves a description of the device's mimic and stores this description in 'InformationManager. unit [i]. mimic. HTML' where i is the unit's stack index. This description is processed by the Mimic Manager and written into the

Mimic document object's 'unitniimic' child object. The 'initialize' function in the Mail] frame reads the unit summary information from the Information Manager, formats it as a

* HTML table and inserts it in the 'unitsummary' child object. The notepad is not retrieved from the device until the first tline that the Mlinc document object beconles, visible. 01) retrieval, the notepad i's inserted into the 'unitnotepad 'child object.

The Mimic Manager and its related objects are shown in Figure 59.

When a Mimic document object is made visible (via Viewmanager. display), a periodic polling task is scheduled. This polling task requests the retrieval of encoded port and device information from the device by invoking, the method InterfaceManager. get. The retrieved information is delivered to the PollReply hidden frame. When polled, the device reads the M1Bs and encodes the port information in Javascript program. This program invokes MirmeManager. update which decodes the port information and updates the mimic if necessary. The polling task's upper and lower limits for the polling interval are declared in the Information Manager (browser. pollInterval). The polling task is cancelled by specifying a polling interval of 0 seconds. When a Mimic document object is rnade hidden (e.g. if the user selects another mimic or another view), the polling task is cancelled.

1 1 The device mimic consists of a HTML description of the device. The mimic is composed of a number of discrete components which are assembled to form a full image. The mimic components include:

The front panel (Ethernet) ports.

The console port.

The unit 'superstructure' - e.gy. top and bottom edges, left and right sides.

Interior details - e.g- number plates, LED panels.

Expansion ports.

Transceiver modules.

Figure 60 shows a mimic of an 'assembled' 24 port network switch.

The subirnagie components which may be used to assemble the mimic illustrated in Figure 60 include those shown in Figure 61, which relates a description to the correspoildincy irnaCFe.

Image components can be divided mages and variant ima(yes.

I into two groups invariant 1 Invariant images are typically used to display structural elements which are time independent, e.g. top and bottom edges, left and right edges, port numberplates, the console port, the corporate logo etc. Variant images display time-varying information usin- a visual encoding mechanism. Ethernet ports are variant since the status of a port and its associated link may change over time. Variant images names use tile same encoding scheme used by the tab images.

Irnage subcomponents can be made clickable so as to provide 'hotspots' on the device mimic. A hotspot is declared by enclosing it within a hyperlink, as shown in Figure 62.

1 1 The value of the href attribute encodes information about the hotspot type. The general I format of the href attribute is shown in Figure 633. In Figure 63) 1 is the unit's stack index and T indicates the hotspot type. The hotspot type is a one letter code which describes the hotspot region, followed by an optional port number. At present, the two known platforms contain three hotspot regions - the Ethernet ports, the console port and the unit itself For these types, the allowable values of T are 'U' (Unit)l 'P' (Front Panel Port)-, and 'C' (Console Port).

The code fragments illustrated in Figure 64 show examples of the use of the 'href attribute to encode information about the hotspot type.

The <Imu> ta- attributes contain information about the image name and dimensions. The =5 n n I - - border attribute is always set to 0 to prevent the display of the enclosing hyperlink's border. The name attribute is optional and is generally used in the context of variant images, such as Ethernet ports. If present, the name attribute encodes the port type S (front panel, expansion, transceiver etc), the stack index I and the port index P, as summarized in Figure 65.

The port type/narne identifier S is a string of alphanumeric characters with no embedded spaces. When the iniage represents a port, tile following values are used E = Ethernet port.

X = Expansion port.

T = Transceiver port.

The examples shown in Figure 66 illustrate the use of the name attribute.

I For purposes of signalling the completion of mimic insertion in the Nightingale client, the last irna,,e in the mimic (e.g in the bottom right corner) is always labelled bottomright in the name attribute.

The src attribute is used by the browser to retrieve the image file associated with the subimage. This is normally stored in the 'gifs' directory.

The width and height attributes provide important dimensioning information to the browser and thereby facilitate higher rendering speeds. These attributes also facilitate the use of stretchable images. Certain subimages have a high amount of horizontal and/or vertical repetition. In these cases, it is only necessary to store a one- pixel wide/high image I I and instruct the browser to stretch it to the desired dimensions. This technique effects considerable savin-s in device memory- The use of the 'src. width. height' and 'border' attributes is illustrated in Figure 67.

Figure 68 illustrates by way of example a mimic with six built up layers, This is typical of 1.5 U high device inimics in general.

The dimensions of the layers in Figure 68 are shown in Figure 69. The total height is 106 pixels.

Layer I in Figure 69 i's the unit's top edge. It consists of three separate images - the left edLye ( 15 pixels wide), the top middle section (444 pixels) and the right edge (6 1 pixels).

The left and right edge sections are stored in uncompressed format. The top middle section contains horizontal repetition and can therefore by stored as a I pixel wide image.

The laver I iniage diniensions are listed in Fioure 70. The 'Stretch' colunin indicates whether an irna,,-Ye can be stretched by the browser and in which direction. An entry of 'H' means that the image is horizontally stretchable, and an entry 'V' means that the iniage is vertically stretchable.

Layer 2 contains the top part of the LED panel. The LED panel is an invariant image - tile port LEDS do not indicate the port's link state or activity level. Layer 2 also contains tile expansion ports. There may be up to 4 ports in an expansion module. The layer 2 dimensions are listed in Figure 71.

Layer 3) contains the top batik of front panel Ethernet ports and the middle section of the LED display. In a 12 port device, such as shown in Figure 72, the 'top' ports are absent.

In this case, the space normally reserved for the ports is replaced with a blank. The layer 2 imaue rn 2 2.crif can be reused for this purpose.

11:1 - - -1 The Layer 3 3 image dimensions are as shown in Figure 7-3).

Layer 4 provides a thin amount of 'whitespace' to separate the top bank of front panel ports from the bottom panel. The layer 4 images are as shown in Figure 74.

In Note that m 2 2.g1f can be reused in this layer to provide the central grey space.

Layer 5 contains the bottorn bank of front panel ports and the bottom section of the LED panel, layer 5 also contains the console port. IN the case of a 12 port device, the bottom section of the LED panel is absent and can be greyed out using m 2-2.-'f The layer 5 D imagres are as shown in Figure 75.

Z Layer 6 contains the bottom edge of the mimic. The iniages are as shown in Flaure 76.

The Window Manauer is responsible for opening and managing child windows. Clicki I -- 11) 1 1 1 ing on a command icon in the navigation normally results in the opening of a dialog box 0 Z containing a form or Wizard. The Window Manager generates a new window and computes its dimensions and screen location. It also ensures that only one command window is open at any one tirne. If a window is open and the user attempts to open another the Window Manager brinp the opened window back into focus. The methods and fields of the Window Manazer are as shown in Figure 77.

The Window ManaveF is also responsible for opening, the 'Help' window, which is activated by the user In the Help view. The Window Mana0er interacts with the Dialog Box and the Interface Manager as shown in Figure 78.

The field 'dialogBox' is a reference to the child window when a dialoc, box is opened.

This field is used by this and other objects to communicate with the dialog box, primarily t) I the writing of information into a form and the invocation of a function within the dialog box.

The field 'helpWindow' is a reference to the child window when a help window is opened.

The field unit' records the unit number of the devices associated with the Dialog Box.

The field 'form' contains a reference to a form object, typically a form contained in the

Dialog Box.

I The method 'open' is invoked to generate a new child window for dialog boxes and help 11 In windows. This method is invoked by the Tree Manager. The open method supports a number of launch methods as shown in Figure 79.

The methods 'ok.cancel' and 'unload' provide the Dialog Box with the 'standard' window Z> controls, narriely the ability to close the window via the OK. Cancel and 'x' buttons respectively.

The 'get' method is used by the Dialog Box to obtain data for display oil its forms When invoked, this method copies the form reference to WindowManager.forni, It then makes a I request to the Interface Manager in order to retrieve device parameters from tile device.

The resource is retrieved from tile device and returned to the FormReply hidden frame.

When the requested resource is retrieved from the device, it invokes the method InterfaceMana-er.handleReply. This method in turn invokes W i nd owManager. writ eFo rill.

The method Wi ndowMana oer. writ eForrn reads the value of the form field and invokes

WindowManager.UpdateForm which causes tile information retrieved from tile device to the displayed in tile specified form object.

The Dialog Box provides the primary means of user interaction with the device. The I Dialog Box typically contains one ore more form ob. ects which display the device's J current parameter values when first displayed as well as a set of alternative parameter values which may be applied. The contents of the Dialog Box depend on the invoked command, but typically, contains one or more form objects and a set of window control buttons e.g. OK and Cancel. When the Dialog Box is used to display a Wizard, it typically contains a set of Wizard control buttons - Next, Back, Finish.

Dialog Boxes also contain methods for initializing the information display, validating user input, updatino screen sections and data processing, as shown in Ficrure 80.

ZD ID The Dialog Box interacts with the Window Manager and the Information Manac'er. When a Dialog Box is opened, it requests the information for display in its form (or forms) by invoking WindowMana-er.-et- This causes the device parameters relevant to the selected Dialogy Box to be made visible in the specified form object as shown in Figure 8 1.

When the user clicks the OK or Finish button, the Dialog Box invokes WindowsMana er.OK. This method accepts a Boolean parameter indicating whether the 9 form object contains validated information. This parameter is supplied by the result of tile Dialo-Box. validate method. In the case of Wizards of dialog boxes with multiple forms, the validate function is also responsible for copying fields from one form object to another, Only one form object may be submitted via the OK or finish button.

The Tree Manager is responsible for building the navigation tree in each view. It also dynamically attaches onclick handlers onto the clickable elements of the tree. The navigation tree is modelled on the Windows 95 Disc Explorer tree, and contains methods to expand and contract tree folders. The fields and methods of the Tree Manager are shown in Figure 82.

The Tree Manager interacts with the Tree docurnent objects, the Information Manager, the I Interface Manaaer, the Windows Manager, the View Manager and the Mimic Manaoer.

=1 The method 'clickHandler' is responsible for trapping click events on the tree's hotspots, namely the tree expansion control points (the '+' and '-' icons), the root icon, the device icons and the command icons. When a command icon is clicked, the Tree Manager invokes 'WindowManager. open' which then displays the selected command ill a child 11) window. The 'method attach' is responsible for associating the click event with the hotspot's 'onclick' handier.

The Server Architecture The client communicates with an HTTP server resident in the device. From the point of view of the server, its resources are either static (stored in the file system and delivered unaltered to the client) or dynamic (executable files requiring the scripting engine to process). Static files are, for example HTNIL files, GIF images, style sheets, Javascript programs. Dynamic files are executed by the scripting en"ine.

For purposes of efficiency and simplicity, the invention decouples the HTML content from the data content, particularly in dialog boxes associated with device commands. In 1 -eneral, the HTNfL content of a dialog box is a static resource which is not Cenerated by 0 the server's scripting engine, while the data content is dynamic, generated oil demand when a dialog box is opened.

The server script falls into two main categories, data generation and data processing Data generation occurs when a dialog box is opened. A server script is executed to deliver the data required to set the appropriate fields in the form. Such a script typically reads a series of 1\41B values and inserts the responses in a Javascript function call, which is delivered to the Interface Manager for processing, Data processing occurs when a dialog box is closed (by clicking its OK button). A form containina the user's settinas is submitted to the server. These settings are analysed by a C> data processing script and the appropriate action is taken. In general, the data processing 1 -D In script writes a sequence of values into a MIB. Unlike current Web interfaces, the architecture does not require the data processing script to regenerate the HTML content I I - and applied setting by way of response. The data processing, script inserts its response code in Javascript function call which is delivered to the Interface Manager for handling I and processing. The response code contains information about the completion status of the operation, including informational or error messages.

The data generation scripts are preferably retrieved using the HTTP GET method. The script may require the use of a parameter in order to conditionalize its action. For example, a data -eneration script which return port information may require the desired port number to be passed to it.

The data processing scripts are preferably invoked using the HTTP POST method and the parameters are normally derived from a HTML form object. The parameters are retrieved by the script, validated and applied to the MIB.

The relationship between the data generation scripts, the data processing scripts, the HTTP methods and the M1Bs is shown in Figure 83.

The structure and content of the server scripts are discussed in the following two sections.

Data Generation When a dialog box is launched, the HTML content is inserted and displayed. The HTML typically consists of one or more di alogs constructed with the <form> taa. These forms serve two purposes. One is to display the current state of the device or stack (e.(),,. Ethernet port link- state, console port connection, spanning tree configuration). A second is to present a set of possible alternative states which may be applied (e.g. change a port from enabled to disabled, set the spanning tree forwarding delay to 25 seconds etc).

The dialog box obtains the current state by making a request to the Information Manager.

I I I The format of the request is shown in Figures 84 and 85.

The server resource name is the name of the data generation script without a file suffix.

The file suffix is obtained from the Information Manager and appended to the resource name. If the data generation script is parameterized (e.g. port number, unit number etc) then the parameters are supplied as a striner in the 'parameters' argument. The following code fraument shown in Figure 86 illustrates the use of the WindowMana-er. oret method I -- In It) from within a dialog box.

In the above case, the console Cret script does not require parameters, so the 'parameters' ar-ument is the null string The method WindowManager.get copies the form reference to the field

WindowManaaer.form, it then invokes InterfaceManacrer.oet to request the retrieval of the Z:> = 1- resource from the device, which is then returned to the FormReply hidden field. The data -eneration function crenerates a Javascript program which is executed by the browser when it loads in the hidden frame. In general, the program signals the completion of the C01111111-inication transaction to the Interface Manager by invoking the method IiitefaceMaiiacrer.liaiidleReply. This method analyses the response code and if successful, it 'invokes WindowManager.writeForm method obtains the reference to the form object from WindowMana-er.forin and invokes WindowManagger.updateForm, which then Causes the information to be displayed in the form.

The sequence of steps invoked in obtaining the information for display in a form belonging to a dialog box shown in Figure 87.

Step I The dialog box invokes WindowManager.get, which in turn invokes 1 17. In InterfaceManaaer.-et. A HTTP GET message is sent to the device which results in the execution of the required generation script.

Step I The script is executed and a Javascript program is generated. This is returned to the Forn-LReply hidden frame. On execution, the response function invokes IiiterfaceManao,er.liaiidleReply, which in turn invokes WindowManaoer. writeForm. The method writeForrn reads the form reference from WindowManager-form and invokes the method WindowManager.updateForm, which then modifies the form elements in the specified form so as to display the device's current parameters, as shown in Figure 88.

The information obtained by the generation script is encoded in the Javascript response function. The encoding scheme uses a series of name-value pairs. The name component corresponds to the name attribute of the field in the form, and the value component is a valid value for the form element type.

There are three major classes of form fields- the <Input> field and the <selection> field.

The <Input> element's type attribute determine the exact structure of the field. The table shown in Figure 89 lists all possible type attributes and the required formatting of the response code.

Note that in the case of <input type=text> fields, the returned value is the URL encoded string obtained from the plain text string in the MIB. Such fields are used to store parameters such as device name, contact, location, port label etc.

The <textarea> tag is used to display a multiline text box. When present, the encoding is used as shown in Figure 90. This element may be used for a notepad display.

I The third class of form field is created using. the <select> tag. Tills is used to generate pull-down menus and scrolling lists. The <select> tag requires one or more nested <option> elements. The options are either single-one or select-multiple. Figure 91 defines the encoding which may be used for both of these types.

The response codes are concatenated into a single string and enclosed in a Javascript function call as shown in Figure 92.

Each parameter and its respective type and description may be as follows: 'Status' is a number which indicates success or failure of the read operation. The code 2 may represent Normal completion whereas 4 may represent one or more errors encountered, 15 'Reason' is a string which is a textual description of the success/fail condition. The intended use is to provide text for use in an alert box. 'ScriptName' is a string naming a function to be invoked on successful completion. 'ScriptParai- neters' is a string identifying parameters to be passed to function on successful completion. 20

In the case of dialog boxes, the scriptName argum. ent is set to "WindowManager.writeForm". An example is shown in Figure 9' 3.

Z.

Data Processin When the user clicks the 'OK' button on a dialog box, the selected settinas are submitted and applied to the MIBs. A form object is submitted to the device and a data processing device resource is invoked in order to decode, validate and apply the settinas as in Figure 30 94.

The form processing script accepts the submitted form parameters and if valid, applieds them to the MIB. The form processing script is required tosignal the completion of the transaction by returning a Ja,,,ascript response function. The response function causes the dialog box to be closed, thus signalling the completion of the command to the user. This is achieved by callin, Windov.-Nianager.cancel. The response function may perform other functions. For example, if the user changes a value that is mirrored in tile Information Manager, the response function may update the mirrored value. If the user changes a parameter which has a visible representation on the client, then the interface must be updated to reflect the change. For example, if the user changes the name of the device, the response function must update the device name in the InformationManager and also request the regeneration of the HTML table which displays the device narne, as indicated in Figure 95.

The architecture described has the following advantages.

It is built upon open standards (e.g. W-3)C - the World Wide Web Consortium).

It does not requires a plugin player or Java Virtual Machine.

It requires a smaller memory footprint than JVM-based architectures.

It does not require the installation and configuration of a plugin player. It has a faster response rate than the JVM-based architectures. It uses standard HyperText Transfer Protocol rather than not proprietary systems for 25 communication.

Dialog Boxes are built using static HTML and can therefore be cached for rapid retrieval.

I The dynamic scripts are considerably simpler and faster than hither-to.

041,111s 1 A tietwork device which includes an embedded Web server ca able of HTML page p It) (iciieratioii and organised to crenerate separately the layout of a page and the variable 1 1:1 information to be displayed on the page.

2. A device according to claim 1 wherein the page layout is stored as a static file and said In device includes a scripting engine for generating the variable information.

3. A device according to claim 2 wherein the scripting, engine generates a Javascript It) It> C> It> program to set or update the displayed variable information.

4. A device according to any foregoing claim wherein the page constitutes a mimic of the network device.