EP0815518A1 - Rechnersystem und verfahren zur herstellung und erhaltung von online-diensten - Google Patents

Rechnersystem und verfahren zur herstellung und erhaltung von online-diensten

Info

Publication number
EP0815518A1
EP0815518A1 EP96908850A EP96908850A EP0815518A1 EP 0815518 A1 EP0815518 A1 EP 0815518A1 EP 96908850 A EP96908850 A EP 96908850A EP 96908850 A EP96908850 A EP 96908850A EP 0815518 A1 EP0815518 A1 EP 0815518A1
Authority
EP
European Patent Office
Prior art keywords
server
client
machine
authoring
document
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP96908850A
Other languages
English (en)
French (fr)
Inventor
Peter R. Amstein
Thomas P. Blumer
Arthur L. Coburn, Iv
Randy J. Forgaard
Andrew J. Schulert
Ted Stefanik
Robert J. Mauceri
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Corp
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US08/406,360 external-priority patent/US5732219A/en
Priority claimed from US08/566,281 external-priority patent/US5793966A/en
Application filed by Microsoft Corp filed Critical Microsoft Corp
Publication of EP0815518A1 publication Critical patent/EP0815518A1/de
Ceased legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/95Retrieval from the web
    • G06F16/958Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00Handling natural language data
    • G06F40/10Text processing
    • G06F40/166Editing, e.g. inserting or deleting

Definitions

  • This invention is related to computer systems for authoring electronic documents, other information and computer programs. More particularly, this invention is related to computer systems for creating, developing and/or modifying on-line services in a client-server information system.
  • An on-line information system typically includes one computer system (the server) that makes information available so that other computer systems (the clients) can access the information.
  • the server manages access to the information, which can be structured as a set of independent on-line services.
  • the server and client communicate via messages conforming to a communication protocol and sent over a communication channel such as a computer network or through a dial-up connection.
  • Typical uses for on-line services include document viewing, electronic commerce. directory lookup, on-line classified advertisements, reference services, electronic bulletin boards, document retrieval, electronic publishing, keyword searching of documents, technical support for products, and directories of on-line services, among others.
  • the service may make the information available free of charge, or for a fee and may be on publicly accessible or private computer systems.
  • Information sources managed by the server may include files, databases and applications on the server system or on an external computer system. The information that the server provides simply may be stored on the server, may be converted from other formats manually or automatically, may be computed on the server in response to a client request, may be derived from data and applications on the server or other machines, or may be derived by any combination of these techniques.
  • the user of an on-line service uses a program on the client system to access the information managed by the on-line service. Possible user capabilities include viewing, searching, downloading, printing, and filing the information managed by the server. The user may also price, purchase, rent, or reserve services or goods offered through the on-line service.
  • an on-line service for catalog shopping might work as follows. The user runs a client program on the client system and requests a connection to the catalog shopping service using a service name that either is well known or can be found in a directory. The request is received by the server, and the server returns an introductory document that also asks for an identifier and password.
  • the client program displays this document, the user fills in an identifier and password that were assigned by the service in a previous visit, and the user's information is sent to the server.
  • the server verifies the identifier and password against an authorization database, and returns a menu document that is then presented to the user.
  • the server responds with the appropriate new page of information, possibly including item descriptions or prices that are retrieved from a catalog database.
  • the server receives the order request, and returns a form where the user fills in some information about shipping and billing.
  • the user response is returned to the server, and the server enters the order information into an order database.
  • On-line services are available on the World Wide Web (WWW), operating over the global Internet in which a large number of computers, or sites, are interconnected. Similar services are available on private networks that may not be connected to the Internet, such as internal corporate LANs.
  • the WWW and similar private architectures provide a "web" of interconnected document objects. On the WWW. these document objects are located on various sites on the global Internet.
  • the WWW is also described in "The World-Wide Web. " by T. Berners-Lee. R. Cailliau. A. Luotonen. H. F. Nielsen, and A. Secret, Communications of the ACM. 37 (8), pp. 76-82. August 1994. and in "World Wide Web: The Information Universe.” by Berners-Lee, T.. et al.. in Electronic Networking: Research. Applications and Policy. Vol. 1. No. 2. Meckler. Westport. Conn.. Spring 1992.
  • HTML documents that are published on the WWW are written in the Hypertext Markup Language (HTML), such as described in HyperText Markup Language Specification - 2.0. by T. Berners- Lee and D. Connolly.
  • HTML documents stored as such are generally static, that is. the contents do not change over time unless - J - the service developer modifies the document.
  • Scripts are programs that can generate HTML documents when executed.
  • HTML is a language used for writing hypertext documents.
  • the formal definition is that HTML documents are Standard Generalized Markup Language (SGML) documents that confor to a particular Document Type Definition (DTD).
  • An HTML document includes a hierarchical set of markup elements, where most elements have a start tag. followed by content, followed by an end tag. The content is a combination of text and nested markup elements. Tags are enclosed in angle brackets (' ⁇ ' and '>') and indicate how the document is structured and how to display the document, as well as destinations and labels for hypertext links. There are tags for markup elements such as titles, headers, text attributes such as bold and italic, lists, paragraph boundaries, links to other documents or other parts of the same document, in-line graphic images, and many other features.
  • a hypertext document may also have a link to other parts of the same document.
  • Linked documents may generally be located anywhere on the Internet. When a user is viewing the document using a client program called a Web browser (described below), the links are displayed as highlighted words or phrases. For example, using a Web browser, the sample document above would be displayed on the user's screen as follows:
  • a script is an executable program, or a set of commands stored in a file, that can be run by a server program called a Web server (described below) to produce an HTML document that is then returned to the Web browser.
  • Typical script actions include running library routines or other applications to get information from a file or a database, or initiating a request to get information from another machine, or retrieving a document corresponding to a selected hypertext link.
  • a script may be run on the Web server when, for example, the end user selects a particular hypertext link in the Web browser, or submits an HTML form request.
  • Scripts are usually written by a service developer i an interpreted language such as Basic.
  • Perl Practical Extraction and Report Language
  • Tel Tool Control Language
  • C Unix operating system shell languages
  • URI Universal Resource Identifier
  • T. Berners-Lee "Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web.”
  • a URI allows any object on the Internet to be referred to by name or address, such as in a link in an HTML document as shown above.
  • URN Universal Resource Name
  • URL Uniform Resource Locator
  • a URN references an object by name within a given name space.
  • the Internet community has not yet defined the syntax of URNs.
  • a URL references an object defining an access algorithm using network protocols.
  • An example URL is "http://www.vermeer.com”
  • a URL has the syntax "scherne://host:port/path?search” where "scheme” identifies the access protocol (such as HTTP. FTP or GOPHER);
  • host is the Internet domain name of the machine that supports the protocol:
  • port is the transmission control protocol (TCP) port number of the appropriate server (if different from the default):
  • path is a scheme-specific identification of the object: and
  • search contains optional parameters for querying the content of the object.
  • URLs are also used by web servers and browsers on private computer systems or networks and not just the WWW.
  • a site that wishes to make documents available to network users is called a "Web site” and must run a "Web server” program to provide access to the documents.
  • a Web server program is a computer program that allows a computer on the network to make documents available to the rest of the WWW or a private web.
  • the documents are often hypertext documents in the HTML language, but may be other types of document objects as well, as well as images, audio and video information.
  • the information that is managed by the Web server includes hypertext documents that are stored on the server or are dynamically generated by scripts on the Web server.
  • Web servers have been implemented for several different platforms, including the Sun Sparc 1 1 workstation running the Unix operating system, and personal computers with the Intel Pentium processor running the Microsoft MS-DOS operating system and the Microsoft Windows operating environment.
  • a gateway is a program that handles incoming information requests and returns the appropriate document or generates a document dynamically. For example, a gateway might receive queries, look up the answer in an SQL database, and translate the response into a page of HTML so that the server can send the result to the client.
  • a gateway program may be written in a language such as "C” or in a scripting language such as Perl or Tel or one of the Unix operating system shell languages.
  • the CGI standard specifies how the script or application receives input and parameters, and specifies how any output should be formatted and returned to the server.
  • a Web server machine may limit access to files.
  • the Web server program running on the server machine may provide an extra layer of security above and beyond the normal file system and login security procedures of the operating system on the server machine.
  • the Web server program may add further security rules such as: 1 ) optionally requiring user name and password, completely independent of the normal user name and passwords that the operating system may have on user accounts. 2) allowing definitions of groups of users for security purposes, independent of any user group definitions of the operating system. 3) access control for each document object such that only specified users (with optional passwords) or groups of users are allowed access to the object, or that access is only allowed for clients at specific network addresses, or some combination of these rules.
  • a user typically using a machine other than the machine used by the Web server
  • the browser program allows the user to retrieve and display documents from Web servers.
  • Some of the popular Web browser programs are: the Navigator browser from NetScape Communications Corp.. of Mountain View. California: the Mosaic browser from the National Center for Supercomputing Applications (NCSA): the WinWeb browser, from
  • HTTP Hypertext Transfer Protocol
  • TCP/IP transmission control protocol/internet protocol
  • HTTP is described in Hypertext Transfer Protocol - HTTP/1.0. by T. Berners-Lee. R. T. Fielding. H. Frystyk Nielsen. Internet Draft Document. October 14. 1995. and is currently in the standardization process.
  • HTTP the Web browser establishes a connection to a Web server and sends an HTTP request message to the server.
  • the Web server checks for authorization. performs any requested action and returns an HTTP response message containing an HTML document resulting from the requested action, or an error message.
  • the returned HTML document may simply be a file stored on the Web server, or it may be created dynamically using a script called in response to the HTTP request message. For instance, to retrieve a document, a Web browser sends an HTTP request message to the indicated Web server, requesting a document by its URL. The Web server then retrieves the document and returns it in an HTTP response message to the Web browser. If the document has hypertext links, then the user may again select a link to request that a ne document be retrieved and displayed. As another example, a user may fill in a form requesting a database search, the Web browser will send an HTTP request message to the Web server including the name of the database to be searched and the search parameters and the URL of the search script.
  • the Web server calls a program or script, passing in the search parameters.
  • the program examines the parameters and attempts to answer the query, perhaps by sending a query to a database interface.
  • the program receives the results of the query, it constructs an HTML document that is returned to the Web server, which then sends it to the Web browser in an HTTP response message.
  • Request messages in HTTP contain a "method name" indicating the type of action to be performed by the server, a URL indicating a target object (either document or script) on the Web server, and other control information.
  • Response messages contain a status line, server information, and possible data content.
  • the Multipurpose Internet Mail Extensions (MIME) are a standardized way for describing the content of messages that are passed over a network. HTTP request and response messages use MIME header lines to indicate the format of the message. MIME is described in more detail in MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies. Internet RFC 1341. June 1992.
  • the request methods defined in the current version of the HTTP protocol include GET.
  • the GET method requests that the server retrieve the object indicated by the given URL and send it back to the client. If the URL refers to a document, then the server responds by sending back the document. If the URL refers to an executable script, then the server executes the script and returns the data produced by the execution of the script. Web browser programs normally use the GET method to send request messages to the Web server to retrieve HTML documents, which the Web browser then displays on the screen at the client computer.
  • the PUT method specifies that the object contained in the request should be stored on the server at the location indicated by the given URL.
  • the ⁇ simply handle all PUT requests through a single PUT script, which is generally undefined, and must be created by a service author. Web browsers generally do not use the PUT method.
  • the POST method sends data, usually the user input parameters from an HTML form, to the server.
  • the POST request also contains the URL of a script to be run on the server.
  • the server runs the script, passing the parameters given in the request, and the script generates
  • HTML output to be returned in the response to the client In order for a client program to send arbitrary data to the Web server using the current HTTP protocol, the client program must use either the PUT method or the POST method, as these are the only two methods that allow such data transfer to the Web server. Web browsers generally use only the POST method and generally only for the purpose of sending data in connection with forms to be processed.
  • An on-line service for use on a web architecture includes a Web server program running on a Web server machine, and a set of service files that characterize the on-line services that are stored on the Web server machine.
  • Th service files include HTML documents, executable scripts or programs to dynamically produce HTML documents, and other files of service information that can be referenced and updated by the scripts and programs. The actual data and scripts that make up a particular on-line service.
  • an on-line service might consist of a corporate home page which is a document, with a link to a second document that is a form for searching the store catalog.
  • the search form may have a "submit" button that causes a script to be run on the Web server, to generate a list of product descriptions with prices that is then returned to the Web browser as an HTML document.
  • Each of the HTML documents may have a link to a second script that collects and displays the items that have been ordered.
  • the service also has configuration information such as the list of authorized users of the service, and their passwords.
  • Figure 1 shows the steps in using an on-line service, as seen by the end user of the on-line service on the client machine.
  • the end user starts a Web browser program in step 10. and the program determines the URL of an initial document to display in step 12.
  • the initial document URL may be determined from a configuration file, or may be programmed into the Web browser, or may be entered by the user.
  • the browser then sends an HTTP GET request to the Web server in step 14. giving the URL of the desired document.
  • the browser then waits for a response from the Web server in step 16.
  • the browser tests the response in step 18 to determine if it indicates an error message. If the response message from the Web server indicates an error, for instance if the requested document is not found, then the browser reports the error to the end user in step 22.
  • the browser waits for the user to enter the next command (step 24). For example, the user may request to view a new document by selecting a hypertext link to a document, by requesting a document from a list of previously visited documents, or by typing in the URL of a document that was obtained by the user through some other means.
  • the browser tests the user command to determine if the user is requesting a new document in step 26. If so, processing continues at step 14 which has already been discussed. If the user is not requesting a new document then the browser tests the command in step 30 to determine if it is a request to exit the program.
  • the command is a local command that is handled by the browser without sending an HTTP request in step 28.
  • the end user may use local viewing commands such as commands to scroll around in the document, or commands to search for a particular text string in the document.
  • the browser After the browser handles the local command, the browser again waits for the next user command as already discussed, in step 24.
  • Figure 2 shows the operation of an on-line service as seen by the Web server program.
  • the server runs continuouslv. waiting to receive a command over the network connection from a client Web browser program in step 40.
  • the server tests the received command in step 44 to determine if it is a GET request. If it is a GET request, then the server examines the URL contained in the request in step 52 to determine if the URL indicates a HTML document stored on the server. If the URL does refer to a document then that document is 5 returned to the Web browser via an HTTP response in step 58. Otherwise the URL indicates a script stored on the server, and the Web server runs the script to produce an HTML document in step 56 which is then returned to the Web browser as described before in step 58.
  • step 44 determines that the command is not a GET request
  • the server tests the command in step 48 to determine if it is a POST request. If so. the server retrieves the parameters from the l() POST request in step 54. which include the URL for the script and the parameters for the script. The server then runs the indicated script in step 56 to generate an HTML document which is then returned to the Web browser as described before in step 58. After an HTML document is returned to the Web browser, processing continues at step 40. If the test of step 48 determines that the command is not a POST request then the server returns an error message to the Web
  • step 50 formatted as an HTML document.
  • the processing continues at step 40 and the server again waits for the next request and the process repeats.
  • On-line services such as those described above are in high demand. Unfortunately, the task of developing an on-line service is currently one that almost always requires extensive programming skill and much specialized knowledge. There exists a great need for tools that will 0 simplify the process of building an on-line service so that the process will take less time, be less error prone, and can be done by a nonprogrammer. In some cases, software tools exist to help convert the data content for the service from its native format to the format required by the server, but these tools only address the conversion of data files.
  • the 25 author performs a combination of the tasks, such as creating a ne HTML document for hypertext included in the on-line service, creating a new script included in the on-line service, retrieving and modifying an existing HTML document from the Web server machine, retrieving and modifying an existing script from the Web server machine, and storing an HTML document or script on the Web server machine so that the Web server program will have access to it.
  • a combination of the tasks such as creating a ne HTML document for hypertext included in the on-line service, creating a new script included in the on-line service, retrieving and modifying an existing HTML document from the Web server machine, retrieving and modifying an existing script from the Web server machine, and storing an HTML document or script on the Web server machine so that the Web server program will have access to it.
  • the service author runs a text or HTML editor program on the same machine as the web server to create or modify the on-line service documents and scripts that are stored on this machine.
  • the problem w ith the first approach is that the service author must be working at the Web server machine, or at least working at a terminal which is directly connected with the server machine. This is not always practical, because the service author may be at a location which is physically remote from the server machine. It also often happens that the server machine requires a high level of security because of the nature of the resources on the server machine that may be shared among a number of users. In this case access to the machine is often limited to the system administrators, and the service author may not have access to the machine for security reasons. For example, the only access to files used by the Web server may be through the Web server alone.
  • the second approach is that the service author may run a terminal emulation program on a client machine to establish a connection to the server machine over a network connection or a modem line.
  • the terminal emulation program allows the user to run programs on the server machine as though the user were working directly on that machine, and with this arrangement the user runs a text or HTML editor program on the server to create or modify the on-line service documents and scripts as before.
  • the second approach has the problem that the server machine and client machine must both run additional programs to allow terminal emulation and remote execution of programs over a network. This adds to the complexity on both machines, and also requires that the service author be familiar with a terminal emulation program which typically has a difficult user interface that is not meant for nonexperts. This approach also adds another route from other machines to the server machine, which may be undesirable for security reasons. As with the first approach, the service author may not have access to the server machine for security reasons, or may not have authorization to write files to the machine.
  • the service author first transfers existing service documents and scripts from the server machine to a client machine either manually or via a network file transfer program.
  • the author then runs a text or HTML editor program on a client machine to create or modify documents on that machine, and then transfers the completed documents back to the server machine either manually or via a network file transfer program, such as the file transfer protocol (ftp) or kermit. a file transfer method used with terminal emulation programs for communication over a modem.
  • ftp file transfer protocol
  • kermit a file transfer method used with terminal emulation programs for communication over a modem.
  • the third approach is cumbersome because of the need for the separate steps of transferring the documents from the server back to the client, and transferring the documents back to the server after the editing is complete.
  • This approach also has the security problems mentioned above for the other approaches.
  • Each of these three approaches also has the problem that the file names used for documents by a Web server are not always the same as the actual file names of the documents. An author of an
  • a general aim of the invention is to provide a client/server system, using a Web server. that allows for the creation and maintenance of an on-line service using a client system which remotely causes the server to perform operations required in the authoring process.
  • Another difficulty in implementation is the choice of communication protocol for transferring information from client to server during the authoring process.
  • Other problems ma arise if a protocol other than HTTP is used. For example, other network services will need to be added, with ensuing security loopholes and added complexity.
  • Another difficulty in implementing a client system for creating and maintaining an on ⁇ line service over the HTTP protocol is that there are two or more types of component document objects for the on-line service that are stored on the Web server. These are HTML documents, and scripts that dynamically generate HTML documents upon request. If an authoring program would like to retrieve a script from the server, using the HTTP protocol, it cannot simply use the HTTP GET method that is normally used to retrieve documents and access scripts during the operation of an on-line service.
  • HTTP GET method when used to access a script, causes the script to be executed and returns an HTML document that is generated through execution of the script.
  • a client program generally does not have a file name space that includes the file names of the document objects of the on-line service on the server. Such an overlap in the file name space generally requires use of a network file system. Creation of a network file system including the authors of all on-line services on a server is generally impractical. Such a system is also generally too complex to set up easily and requires too much close interaction among systems than is practical on a large heterogenous public network like the Internet. In many cases, a client authoring system would not have access to the server anyway to enable the set up of a network file system.
  • Web server programs are generally designed to make documents available only to browser, or read-only, programs which are concerned primarily about document content only.
  • Other characteristics of documents useful in the creation and maintenance of an on-line service are not provided and are generally not accessible.
  • such information is often operating system and server program dependent.
  • the present invention overcomes these difficulties by providing a mechanism through which a client system remotely causes a server system to perform one of a collection of operations which support the creation and maintenance of an on-line service.
  • the server is an HTTP server program
  • these operations may be performed by a server extension program that is called by the server program via the Common Gateway Interface (CGI ).
  • CGI Common Gateway Interface
  • these operations can be implemented directly in the server program.
  • the operations are invoked by the client system when the client sends a message to the server with an indication of the desired operation and the appropriate data content for the operation.
  • the server is an HTTP server program
  • communication between the client and the server relies on HTTP. Results of the operations performed, or an error message, are returned to the client system from the server.
  • the result or error from the operation performed by the server extension program is formatted into an HTML response message by the server program, or by the server extension program.
  • the operations which support creation and maintenance of an online service include at least both reading and writing of document objects. Additionally, other operations can be provided in combination with reading and writing operations to support a graphical user interface for a client application program. For example, operations which enable a user to list document objects of a service or to list the services available on the server may be provided. Operations to create, modify and otherwise maintain meta-information about a service and its document objects are also provided. Operations for creation of a document or service also may be provided.
  • a client application program can use such operations to create and modify information on a Web server for on-line services in a less burdensome fashion than the prior art.
  • more information than merely document objects may be provided on the server, including a set of meta-information.
  • Such information can include service-level meta-information such as the server extension program version, time created, and values for macro variables that are common to many documents in the web. such as phone numbers, addresses and the like.
  • Document-level meta-information may include the author, dates created and last modified, links to other documents, etc.
  • This information is particularly useful for use in a graphical user interface in a client authoring application program, for example, to show types of document objects or how document objects in a service are interrelated.
  • the server extension program given the data content from the client and knowledge of the server and operating system environments. performs server or operating system specific operations to effect the operation requested by the client authoring system.
  • the implementation of these operations on the client side is preferably provided by having a client communication application programming interface (API) which handles all communication transactions with the server.
  • This API has entry points, called by a client application program, that allow an end-user to perform the creation and maintenance operations.
  • This API includes an entry point for each operation which the client authoring application program can invoke.
  • the client authoring application program sets up a procedure to be called - 15 - by the API when the results from the requested operation are received.
  • the client application program may suspend operation or perform other tasks while the API handles transactions with the server which are necessary to perform the requested operation on the server.
  • one aspect of the present invention is a client/server system for authoring an on-line service on a server machine using a client machine.
  • the client machine has an authoring tool for performing authoring operations on information comprising the on-line service.
  • This tool generates requests for authoring operations to be performed on information on the server machine for authoring information on the server machine. These requests are translated into at least one message which is sent to the server machine.
  • the server machine stores information authored using the authoring tool.
  • the server machine also receives the message from the client machine and performs authoring operations identified in the received message so as to author information on the server machine.
  • This information on the server machine is then made accessible by the server machine to other client systems that can be used to access the information without modifying the information, such as a browser.
  • the authoring client machine receives a response message from the server machine, it displays information about performance of the authoring operation by the server, using the response message.
  • Another aspect of the invention is a client system with an authoring tool, as in another aspect of the invention, and which communicates with a server system.
  • Another aspect of the invention is a server system, as in another aspect of the invention, which is configured to communicate with a client authoring tool.
  • the process performed by the combination of the client and server systems, as well as the process performed by the client and the server system individually are also aspects of the present invention. It should be understood that one of ordinary skill in this art can derive other embodiments of these aspects of the invention from the exemplary embodiment shown and that the invention is not limited to this exemplar)' embodiment.
  • the various combinations of one or more these aspects of the invention and one or more features of particular embodiments thereof are also aspects of the present invention.
  • the client machine transmits messages by initiating a TCP/IP connection between the client machine and the server machine.
  • An HTTP request message is constructed which has data, wherein the data content includes information identifying a type of transaction, parameter values for the transaction and a process to be invoked on the server to perform the transaction.
  • This HTTP request message is sent to the server which processes the message to perform the authoring operation.
  • the client machine may also detect reception of an HTTP response message from the server machine.
  • Such a response message has data content carrying data generated by performance of the authoring operation.
  • the client machine may display information about the authoring operation to the user.
  • This HTTP response message may contain data content in a markup language, such as HTML. In such a case, the data content is parsed to obtain information requested from the server.
  • the authoring operations performed by this client/server computer system generally create or modify or store information on the server machine.
  • content of data files on the server can be modified.
  • These data files may be document objects such as documents or scripts of the on-line service. They may also be other media data.
  • the data files may also be meta-information about the on-line service.
  • File information such as access control information, can also be modified.
  • document objects or entire services can be created.
  • Other operations such as listing existing services or document objects of a service, also may be provided.
  • the authoring operations which can be performed may be provided and made available to a user or application programs as collection of primitive operations for authoring an online service.
  • a basic operation to be used is saving a document object on the server. With this collection, each of the primitive operations is individually selectable by a user or application program. Such a collection may be called an application programming interface or API .
  • the server machine runs an HTTP server which receives HTTP request messages.
  • the server machine detects that a message contains a request for an authoring operation to be performed on information on the server computer, the server machine executes a process to perform the authoring operation via a common gateway interface.
  • An HTML document is received as a result of performance of the requested authoring operation.
  • This HTML document is transmitted to the client computer as a result of the requested authoring operation in an HTTP response message.
  • the client computer after sending an HTTP request message, typically executes a process for detecting an arrival of an HTTP response message from the server machine.
  • another process is invoked for completing the authoring operation on the client machine.
  • Such a mechanism can be used in an embodiment not limited to HTTP communication. This mechanism involves establishing a first process for detecting arrival of a response message from the server machine and for executing a second process for completion of the associated authoring operation on the client machine in response to detection of an arrival of a response message from the server machine.
  • the client machine can continue to perform operations which do not depend on results of the authoring operations performed on the server machine.
  • a particular difficulty overcome by embodiments of this invention is where the operating system of the client machine has a file name space which does not include or map to names of files on the server machine. This is typically the case in heterogenous networks such as the
  • the server machine maps file names provided by the client machine into actual file names on the server.
  • This environment allows authoring of an on-line service to be somewhat platform independent.
  • the authoring operations are performed on the server machine by a server extension program executed on the server computer by a server program via the common gateway interface, which allows additional platform and server independence.
  • the server program itself can be implemented to perform these operations directly.
  • This benefit is obtained in one embodiment by utilizing an HTTP method not used by the Web browser, the PUT method, to handle requests from the authoring tool.
  • changes to authoring tool systems can be made transparently to users who merely view information or use an on-line service.
  • this benefit is obtained by using the HTTP POST method with a URL target used specifically for authoring. This URL may be disabled after the service is made available to the browser.
  • Another advantage of this system is that, by using the server extension program to handle authoring activity through a CGI mechanism, a standard HTTP server can be used without modification. Still another advantage of this system over the prior art approaches is that the on-line service author can use a single client program and interface to retrieve a script or document from an existing on-line service on a server, edit or create a script or document for an on-line service, and save the resulting script or document to a known location for authoring on the server.
  • Another advantage of this system is that the author of an on-line service can create, modify or store on-line service documents, scripts and meta-information about the service or document objects from any client machine, so long as the client machine can communicate via HTTP protocol with the Web server that hosts the on-line service.
  • the client machine and server machine may have different types of processors, with different architectures, running different operating systems, in a heterogenous network.
  • Yet another advantage of this system is that the client system communicates with the Web server program using the same type of network connection and the same protocol (HTTP) that is used by a Web browser talking to a Web server.
  • HTTP HyperText Transfer Protocol
  • Still another advantage of this system is that the authoring tool uses the basic authentication procedures provided by the HTTP protocol and the Web server software. Access to files on the server machine may be limited to service authors with a validated user name and password. Thus, by using the HTTP protocol that is already used for on-line services on the World Wide Web. some security is provided during the authoring process.
  • Another advantage of this system is that the authoring process can be used for remote retrieval, editing, and storing of at least two of the types of document objects that comprise an on-line service on the WWW: HTML documents and script programs that generate HTML documents.
  • the system can also be used for retrieving and storing other types of document objects, such as images, video, audio or other media data, for part or all of a web document.
  • Remote authoring of online service document objects using the method of this invention also has several advantages over the prior art approaches, such as remote editing over a network file system where a client machine can read and write files on a remote server machine.
  • One advantage is that this system allows access to the online service document objects only through the Web server program, and thus conforms to the additional security rules implemented by the server program.
  • a second advantage is that since this system uses the existing HTTP protocol mechanism of the Web server machine, the server machine does not have to run additional software or server programs that are required to implement a network file system or shared access to a remote file system from a client machine. This is an advantage because the additional software would add complexity and would add further possibilities for security loopholes.
  • a third advantage is that this system allows access to the online service document objects only through the Web server program, and thus conforms to the document object name mapping conventions between URLs and actual file names of the Web server program. Another advantage of this system is that neither client programs nor service authors need to understand this file name mapping and only need to use the URLs.
  • Figure 1 is a flowchart describing a prior art sequence of activities on the Web browser during operation of an on-line service on the Web;
  • Figure 2 is a flowchart describing a prior art sequence of activities on the Web server during operation of an on-line service on the Web;
  • FIG. 3 is a block diagram illustrating the architecture of a system for creating and maintaining on-line services in accordance with the invention:
  • FIG. 4 shows a block diagram of ho Web information is stored in this invention:
  • Figures 5A-5E illustrate a hierarchical file system including example file names and directory names for information maintained for an on-line service:
  • Figure 6A is an example HTML document used in an example on-line service
  • Figure 6B is an example document meta-information file in the example on-line service
  • Figure 6C is an example service or web meta-information file in the example on-line service
  • Figure 7 is a flowchart describing tasks performed by the client communication interface during a transaction:
  • Figure 8 is a flowchart describing tasks performed by the server machine during a transaction
  • Figure 9 is an example HTTP request message in one embodiment of the invention: and Figure 10 is an example HTTP response message in one embodiment of the invention.
  • FIG. 3 is a block diagram of a computer system for creating and maintaining on-line services.
  • the system includes a client machine 80 connected to a server machine 84 over a communication channel 83 through which the client sends requests 108 and receives responses 1 10.
  • the client machine has a client communications interface module 82 which generates the requests 108 in response to requests, from a client authoring application module 81 executed on the client machine. These requests are made through a client communications application programming interface (API) 85 executed on the client machine.
  • the server machine 84 executes a server program 86 which sends responses 1 10 to the client machine 80.
  • API application programming interface
  • the server program 86 has an associated server extension program 88 which when executed by the server machine, processes requests 108 and generates the responses 1 10 to be returned by the server program 86.
  • the server extension program 88. in response to some requests 108. may be used to access on-line services 90 and 100. These services may be created and maintained using the client application module 81 to generate appropriate documents 92 and 102 and programs 94 and 104.
  • the operating system executed on the client machine has a file name space which does not include or map to names of files on the server machine.
  • the client application module 81 presents a graphical user interface to the end user via a computer screen or display (not shown).
  • the graphical user interface includes an interface for viewing a set of documents and the links between them, and an editing interface for editing a document.
  • This graphical user interface uses standard techniques, including windows, menus, dialog boxes, and push buttons, that are accessed through the keyboard or through a pointing device. From this interface the user may request creation or modification or deletion of any documents within a given service or of the service as a whole.
  • the user may also request an outline view of the web.
  • the outline view starts with the home page document at the top level of the outline, and displays documents that the home page links to as subordinate to the home page document.
  • a given document has links to other documents that are displayed as subordinate to the given document in the outline, unless these other documents have been displayed elsewhere in the outline view.
  • the link map view shows a starting document, all documents that the starting document links to. and all documents that link to the starting document. Each document is displayed as a graphical icon, and each link between two documents is displayed as an arrow from one document to the target document of the link.
  • the link map view may also display further documents that are two or more links from the starting document, in the same manner.
  • the document summary view of the web displays a list of all document objects in the web. and allows the user to sort the list by various characteristics, such as document type, author, title, or date created.
  • the user may also request modifications to auxiliary information, or meta-information. that is stored with the service, such as the name of a service, author information, date and time stamps, user names and passwords, access control information about a document or a set of documents, image or text files that are included by a document, image map information, information about a task list, and executable CGI programs or scripts.
  • This information is provided in this invention as part of an on-line service. This information will be discussed in more detail below in connection with the description of Figure 4.
  • the client application module makes a call to one of the entry points in the client communications interface module. Collectively these entry points are known as the client communications API. This API will be discussed in more detail below, and in connection with the description of Figures 7 and 8.
  • the client machine 80 is a PC with an Intel 80486 or better processor, running the Microsoft Windows 3.1 operating system.
  • the client application module 81 may include any of a variety of document editors, such as HTML editors, text editors, script editors and the like. The exact form of the client application module and the functionality of the editor are up to the needs and desires of the user. However, in this embodiment of the invention such client application module allows the retrieval and storage of a document object on the Web server by generating an HTTP request message as described herein. Existing Web browsers could be modified to provide a storage function and editing capabilities to provide this functionality. Additionally.
  • HTML and other editing tools may also be used in conjunction with this invention if modified to allow for retrieving and storing files on the server by generating appropriate HTTP messages as described below .
  • a large number of HTML editors such as HoTMetaL. from SoftQuad. Inc.. of Toronto. Ontario. Canada, and other document editors and program editors, such as Microsoft Visual Basic may be used to create documents and scripts and the invention is not limited thereby.
  • the client machine 80 may have a dial-up connection to an Internet service provider, typically using a 14.400 baud or faster modem. It may use the Trumpet Winsock 2.
  • Ob application for Microsoft Windows which is Winsock 1.1 compliant to provide a TCP/IP stack with a SLIP connection.
  • the client machine is connected to the Internet and has its own Internet address.
  • the server machine 84 is a Gateway 2000 personal computer with an
  • the Web server program 86 is the CERN Hypertext Transfer Protocol Daemon (HTTPD) server, configured for the Unix operating system.
  • the server machine 84 also has a dial-up connection to an Internet service provider, using a 14.400 baud or faster modem, and using the TCP/IP and SLIP software that comes with the BSDi Unix operating system.
  • the Web server program is the only program providing access to documents and scripts of an on-line service, other than the operating system. It may define groups of users, user names, passwords and file names separately from the operating system of the server machine 84. With this configuration the client and server machines can establish a TCP/IP connection and exchange messages over the Internet.
  • this embodiment is merely exemplary.
  • a large variety of computers and operating systems have suitable server and client software for communicating using HTTP over the Internet.
  • the client and server machines may also be connected by a local area network (LAN), wide area network (WAN) or may even be the same machine, but with different processes communicating together over a common communication channel.
  • LAN local area network
  • WAN wide area network
  • a special-purpose computing system may be used to implement the invention, rather than a commercially-available computer.
  • TCP/IP connection other network communication protocols, including other data transport protocols and message protocols may be used.
  • a variety of message protocols for communicating over TCP/IP connections may be used, such as HTTP. FTP. telnet, etc.
  • the server and the client do not share files through the file name spaces of their respective operating systems. That is. the file name space of the client does not include or map to names of files on the server. In other words, no pair of file names in the two file names spaces corresponds to the same file. More details about setting up client and server machines connected to the Internet and the World Wide Web are discussed in "Setting up Shop on the Internet.” by Jeff Frentzen et al.. and related articles in Windows Sources. February 1995. pp. 42. 64-67. 70. 73-74. 77-80. 106. 108. 1 1 1. 1 13-1 14. 1 17-120. 122. 125. 128. 134-136. 138- 140 and 143. and in How to Set Up and Maintain a Web Site, by Lincoln D. Stein. Addison- Wesley. August 1995.
  • An online service as used in this application, also called herein a "web" is a set of document objects and associated information, stored on a server machine.
  • the documents in the web share certain access control characteristics that are common to the web.
  • the web itself has URL. and each document in the web has a URL that starts with the web URL.
  • the organization of web information in one embodiment is shown in Fig. 4. This embodiment uses a hierarchical file system.
  • each web or service has a location 400 on the server where all the document objects and associated information of the web is stored.
  • the server has a hierarchical file system and the web location is a directory, called the "content " directory, within this file system. All documents and information associated with the web are stored within the file hierarchy based at this director ⁇ '.
  • Another location (not shown) on the server is also used to store the type of HTTP server that is used for the web.
  • the port number associated with the HTTP server, and the location of th configuration information for the server are stored at a globally known location within the file system, such as a predefined subdirectory and file in the file system.
  • HTML documents, image files, and other content files that make up the web are also stored individually in a location 404 on the server. This content will be accessible to the end use of the web using a web browser. Similarly, such content files may be stored at a location 412 in another subdirectory 414 in the file system. This is useful, for example, to provide a separate directory for different types of content files.
  • Meta-information. or information about information is also stored.
  • document meta-information. or information about a particular web document object such as the title of the document, the author of the document, the date and time that the document was created, and the date and time that the document was last modified, may be stored in another location 406 on the server.
  • the document meta-information may also include a list of hypertext links from the document to other document objects.
  • a separate subdirectory of the directory containing the document is provided.
  • a file 408 containing meta- information for a content file is stored for each content file using the file name of the content file to which it corresponds.
  • an additional subdirectory 416 may also include the meta-information files 418 for corresponding content files 412.
  • web meta-information or information about the web as a whole, such as the date and time that the web was created, the version of the server extension program that was used to create the web. and the version of the HTTP server program is stored at a location 410 on the server.
  • the web meta-information also may include the values of some common parameters that are used throughout the web. such as the name and address of the company represented in the web. Parameter values indicating settings of options are also stored in the web meta- information. for instance a parameter value indicating whether this web uses case sensitive URLs or not.
  • Information on the web locking mechanism may also be stored in the configuration subdirectory 402 or other known location for the web such as shown at 428. This information is used to implement a locking mechanism so that the system will correctly handle multiple authors accessing or modifying web information at the same time.
  • Web server specific access control information about each web may also be included, such as list of users and their passwords, definitions of groups of users, and a list of users and groups that may access the web or a particular part of the web. This access control information can also be stored in directory 402 or another known location.
  • a web may also contain other information.
  • a task list 420 of unfinished tasks can be used to guide the web author during creation and maintenance of a web.
  • a database 422 of document dependencies for the web can be stored to provide information about which documents a given document depends on. This database is used to decide when a change to one document should cause a second document or meta information for the second document to be updated.
  • An area 424 for private content that will not be accessible to the end user with a web browser can also be provided. This is used for content that may be included by several documents within the web but that should not be directly accessed.
  • a text index 426 for all text documents contained in the web can be provided for use for text searches of all the documents in the web.
  • An area for CGI programs and scripts that implement the server extensions of this invention should also be allotted.
  • an area for custom CGI programs and scripts that are created by an author may be provided.
  • Figures 5A-5E show an example of the information stored about a web.
  • the server machine is a Sun SparcStation 20 running the Sun Solaris 2.4 operating system
  • the server program is the NCSA HTTP server, version 1.3R.
  • Figures 5A- 5E show a list of documents found in particular subdirectories, and lists the files that store information about the example eb. It also identifies each of the files as belonging to one of the classes of web information discussed above.
  • the web is a "corporate presence" web that has been created by the client/server authoring system of this invention.
  • the web location or content directory is "./contentM where ".” denotes some arbitrary starting point within the hierarchical file system.
  • Each service may be organized as a subdirectory of this "content " directory.
  • a default service in the "content " directory is shown in Figs. 4 and 5A-5E.
  • the format for some of the files that are stored in the "corporate presence '* web on the server machine will now be described with reference to Figures 6A-6C. These files are in essence data structures used by the server program and the server extension program.
  • the document content files are stored as HTML, for example, according to the standard rules of the HTML 2.0 language.
  • Image content files are stored in one of the standard image formats, including the GIF 87. GIF 89A. and JPEG image formats.
  • Figure 6A shows the format of one of the document content files, named "content/prO 1.htm", in the HTML language.
  • a document meta-information file is shown in Fig. 6B.
  • document meta information files store pairs of text strings, where each pair contains a text string for the name of an attribute, and a text string giving the value of the attribute. Each pair is stored as one line of a text file, with each line containing the attribute name, followed by a colon (":”) as separator. followed by the attribute value.
  • Figure 6B shows the format of the document meta information file, named "content/metainfo/prOl .htm”. that stores further information about the document content of Figure 6A.
  • the attribute named "vti_title” has the value "SR
  • ' symbol at the start of the attribute value indicate further information about the format of the value. For example, an attribute value starting with 'S' represents a text string; a 'T indicates a time value: and T indicates an integer value.
  • the attribute "vti cachedbasedtm” gives the date and time of last modification to any of the cached attribute values, in this case "19 Nov 1995 10:47:2 EST".
  • the attribute “vti cachedtitle” gives the document title, in this case "Zephyr Press Release 1 ".
  • the attribute “vti cachedtitledtm” gives the date and time of last modification to the "vti cachedtitle " attribute value, in this case "19 Nov 1995 10:47:50 EST " .
  • the attribute “vti cachedlinkinfo " gives the list of documents that this document links to. in this case the first link is to "images/logo. gif " .
  • the attribute "vti cachedlinkinfodtm” gives the date and time of last modification to the "vti cachedlinkinfo " attribute value, in this case "1 Nov 1995 10:47:42 EST " .
  • the attribute “vti_extenderversion” gives the version number of the server extension program, in this case “1 .0.3.3”.
  • the attribute “vti timelastmodified” gives the time at which the document was last modified, in this case “19 Nov 1995 10:47:33 EST " .
  • the attribute “vti timecreated” gives the time at which the document was created, in this case “19 Nov 1995 10:47:33 EST”.
  • the attribute "vti author " gives the name of the author who created the document, in this case “username " .
  • the attribute “vti modifiedby” gives the name of the author who last modified the document, in this case "username " .
  • FIG. 6C A web meta-information file is shown in Fig. 6C.
  • web meta information files store pairs of text strings, where each pair contains a text string for the name of an attribute, and a text string giving the value of the attribute. Attribute name value pairs are stored as in document meta information files.
  • Figure 6C shows the format of a web meta information file. named "content/_vti_pvt/service.cnf that corresponds to the example of Fig. 6A.
  • the attribute named "vti timecreated” has the value "TR
  • vti_casesensitiveurls indicates whether URLs are case sensitive for this server, in this case the value is " 1 ". meaning yes.
  • the attribute "vti_restartmanual” indicates whether the user must manually restart the server after creation of a web. so that the server can reread its configuration file. In this case the value is "0". meaning that manual restart is not needed.
  • the attribute "vti autorecalc” indicates whether the server extension program must automatically recalculate document dependencies after a document object is saved to the server. In this case the value is "1 ". meaning automatic recalculation is enabled.
  • the attribute "vti longfilenames” indicates whether the server operating system uses long file names, in this case the value is " 1 " meaning that long file names are used.
  • the attribute "vti htmlextensions” gives a list of file extensions that will indicate that a document file is HTML, in this case the list consists of the three extensions “.html”, “.htm”, and “.htm”.
  • the attribute "vti textextensions” gives a list of file extensions that will indicate that a document file is text, in this case the list consists of the extension ".txt”.
  • the attribute "companyemail” gives a macro variable for the company email address, in this case "inf ⁇ ( ⁇ >zephyr.com”.
  • the attribute "companylongname” gives a macro variable for the long form of the company name, in this case "Zephyr Autowerks”.
  • the attribute "companyshortname” gives a macro variable for the short form of the company name, in this case "Zephyr”.
  • the attribute "companyphone” gives a macro variable for the company phone number, in this case "517-890-1000”.
  • the attribute "companywebmaster” gives a macro variable for the email address of the company webmaster, in this case “webmastert ⁇ zephyr.com”.
  • the attribute "companyaddress” gives a macro variable for the company address, in this case “ 123 Piston Drive. Midland. MI 48640”.
  • the attribute "companyfax” gives a macro variable for the company fax phone number, in this case "517-890-1001 ".
  • the present invention allows a client system to remotely perform operations on document objects and associated meta-information of a web by communication with the server program. This communication and the performance of exemplary authoring operations will now be described in connection with Figs. 7 and 8. .
  • Communication between the client application module 81 on the client machine and the server program 86 on the server machine can occur when both machines are connected to their respective Internet service providers or other system providing an equivalent connection.
  • the client and server machines may be the same machine, or on different machines, and in either case a TCP/IP stack program is used to provide a communication path between the client communications interface module and the server program.
  • Communication between the server machine and client machine takes the form of the client sending an HTTP request 108 to the server, the server processing the request, followed by the server replying with an HTTP response message 1 10 to the client.
  • the client communication interface module 82 establishes a TCP/IP connection to the server program 86 and sends the HTTP request message 108 over that connection.
  • the server program 86 receives the HTTP request message 108. performs the indicated processing, and replies with an HTTP response message 1 10 over the same connection. Finally the two programs terminate the TCP/IP connection.
  • a particular HTTP request message (such as a POST message) is received by the server program 86.
  • the server program executes the server extension program 88. for example, in the C++ programming language.
  • other protocols such as FTP could also be used.
  • Different protocols and different messages could be used for both retrieval and storage.
  • FTP could be used to retrieve and HTTP could be used to store, or vice versa.
  • the same type of message is used to process both retrieval and storage of both documents and scripts. The particular message type is not limiting of this invention.
  • the server extension program handles requests to retrieve or store objects in the service data areas 90 and 100 on the server machine.
  • each service data area There are generally two types of objects stored in each service data area: documents in the HTML language 92 and 102. and script programs that generate HTML documents 94 and 104.
  • all communication from the client to the server is initiated through one of the entry points of the client communications interface module API 82.
  • Table I provides a list of procedures in an API which are most useful in an authoring tool.
  • ListServices Return a list of webs on a given port of a given server.
  • ListDocuments Return a list of documents in the web. including lists of links for each document.
  • the client communications interface module implements each of the procedures that collectively make up the client communications API.
  • Each procedure initiates one or more transactions between the client and the server, where a transaction consists of an HTTP request sent from the client to the server, followed by a HTTP response message returned from the server to the client.
  • the client communications interface module 82 sets up a procedure such that completion of all transactions for this API call triggers a 5 call to the procedure.
  • This procedure performs any tasks associated with the completion of the API call. One of these tasks is usually to give the user an indication through the graphical user interface that the user request has been processed.
  • Each client/server transaction follows the same general model.
  • Table II is a list of transaction types used by the foregoing API calls.
  • the client H) communication interface 82 performs the following tasks, as described in connection with Figure 7.
  • the client communications interface module 82 initiates a TCP/IP connection 5 between the client and the server in step 500. Messages in the HTTP protocol will be sent and received over this connection. In the preferred embodiment of the invention a separate TCP/IP connection is established for each transaction.
  • the client communications interface 82 constructs an HTTP protocol POST request message, where the data content of the message carries information identifying the type of transaction, and parameter values or data 0 specific to that type of transaction.
  • the message format is an HTTP message where data needed for the transaction is Forms URL encoded, using key. value pairs. Data content of a put document transaction follows the key. value pairs.
  • Figure 9 shows an example of the format of an HTTP POST request, in this case a POST request for a PUT DOCUMENT transaction.
  • the message consists of eight HTTP header lines, followed by a blank line, followed by the URL 5 form encoded parameter values, followed by a blank line, followed by the HTML document content.
  • the data content of the HTTP protocol POST message can be encrypted.
  • the URL transmitted with the POST message identifies a program that will be invoked on the server machine in order to perform the request.
  • the client communications interface 82 sets up a mechanism (step 504) whereby the arrival of an HTTP response message will trigger a call to a procedure that will handle the completion of the associated transaction on the client system.
  • the transaction with the server is initiated by sending the HTTP protocol POST request message (step 506).
  • the client communication interface module receives a corresponding HTTP protocol response message
  • the client computer may continue to do other tasks that do not depend on the results of the transaction.
  • the client eventually receives an HTTP response message from the server in step 508.
  • the HTTP response message may contain status information or data in response to the client request, or it may contain an error indication if the client request could not be satisfied.
  • Figure 10 shows an example of the format of an HTTP response message, in this case the response to a POST request for a PUT DOCUMENT transaction.
  • the message consists of four HTTP header lines, followed by a blank line, followed by the returned status information and meta information for the document.
  • the document meta information consists of attribute name value pairs in HTML format.
  • the client communications interface module requests termination of the TCP/IP connection for this transaction, then invokes the mechanism established to complete the associated transaction (step 510). If the transaction requires authentication from the authoring client, then the transaction tasks are performed in the same manner, except that the HTTP protocol response message will contain an error message indicating that the client must authenticate the transaction by sending a user name and password. This authentication process is part of the HTTP protocol.
  • the client program requests the user name and password from the user, and the tasks described are repeated with another TCP/IP connection, where the HTTP POST message carries the user name and password in addition to the original parameters.
  • the HTTP server program listens for TCP/IP connection attempts from client machines (step 512). In response to a connection attempt the server program performs the necessary tasks to set up a connection. When an HTTP protocol POST message is received over this connection (step 514). the server program invokes the requested program in step 516. passing parameter information according to the CGI standard mechanism.
  • the program that is invoked by the server is a "server extension" program 88. It should be understood that the server extension program may be implemented as one or several programs.
  • server extension program When the server extension program is invoked, it reads the parameters and data content of the HTTP protocol request message that were passed in according to the CGI protocol. The server extension program parses the message to determine the transaction type and parameters specific to the transaction, and performs the task indicated by this transaction (step 518).
  • the server extension program constructs (step 520) a status message, formatted as an HTML document, indicating that the transaction task was performed successfully. The message also includes any associated data that must be returned to the client for this transaction. If the transaction task was not performed successfully, then the server extension program constructs (step 520) an error message, formatted as an HTML document. In any event, the resulting message is returned to the server according to the CGI standard technique, and the server extension program terminates.
  • the server program receives the status or error message from the server extension program, the server program constructs, in step 522. an HTTP protocol response message containing the HTML document produced by the server extension program, and sends it over the TCP/IP connection to the client communications interface module.
  • the server then requests termination of the TCP/IP connection in step 524.
  • the TCP/IP connection is kept open for more than one transaction, to reduce communication overhead and increase performance.
  • one invocation of the server extension process handles more than one transaction.
  • the client authoring tool calls the GetDocument API procedure to retrieve a document and the associated document meta information from the server machine.
  • the procedure initiates the GET DOCUMENT transaction to retrieve the document and associated meta information from the server.
  • the server extension program on the server receives a GET DOCUMENT transaction, the following steps are performed. First, the indicated document is retrieved on the server machine. Then the document meta information is retrieved for this document.
  • HTML document containing either a status message with the retrieved document and document meta information, or an error message, is then constructed. This document is returned as the response to the server program which in turn sends it to the client communication interface module as described earlier.
  • the client application program calls the PutDocument API procedure to save a modified document to the server machine.
  • the procedure initiates a PUT DOCUMENT transaction to save the modified document to the server.
  • the request message generated for the transaction includes an indication of a location on the server (URL) and the content of the modified document.
  • the server extension program on the server receives a PUT DOCUMENT transaction
  • the program performs the following tasks.
  • the transaction request is parsed into parameter values and data content.
  • the data content is then stored in the indicated document location on the server machine.
  • the data transmitted with the transaction is the new content of the HTML document, or in the case of other types of document objects, such images, scripts, video or audio, is the new content for the document object.
  • the document meta information file associated with the saved document is then located.
  • the document meta information is stored in the "metainfo" subdirectory of the document's directory, under the same name as the saved document.
  • the document meta information file is updated as follows.
  • the value of the "vti_timelastmodified” attribute is changed to the current time, to indicate the time at which the document was last modified.
  • the value of the "vti_modifiedby” attribute is changed to the user name of the author who requested that the document be saved to the server machine.
  • the value of the "vti_cachedlinkinfo” attribute is changed to be the current list of documents or images that the current document either includes or has links to. so that the list reflects any additions or deletions of links in the new version of the document.
  • the value of the "vti cachedlinkinfodtm” attribute is changed to the current time, to indicate the time at which the value of the "vti cachedlinkinfo” attribute was last updated.
  • vti_cachedtitle attribute was last updated.
  • the attribute “vti cachedbasedtm” is changed to the current date and time, indicating the most recent modification to any of the cached attribute values.
  • the attribute “vti extenderversion” is changed to the version number of the server extension program.
  • the attributes "vti timecreated” and “vti_author” are not changed, since these give information about the creation of the document. New attribute key value pairs are added to or updated in the document meta information file for any new attribute information that was received with the transaction.
  • the document dependenc database and the text index of all documents in the web are both updated to reflect the changes in the saved document.
  • the task list of unfinished tasks is also updated to reflect any ne tasks that were generated as a result of the changes to the saved document.
  • An HTML document containing either a status message and the document meta-information. or an error message is then constructed and returned as the response to the server program.
  • the server program in turn sends the response to the client communication interface module as described earlier.
  • the client authoring tool calls the CreateService API procedure to create a new web on the server machine. If necessary, this procedure initiates a SERVER VERSION transaction to retrieve the version number of the server extension programs in order to check compatibility between the client author program and the server extension programs.
  • the procedure then initiates a CREATE SERVICE transaction to create the ne web on the server.
  • the server extension program on the server receives a CREATE SERVICE transaction, the program performs the following tasks.
  • the file that stores the web meta information for the new web is created and the value of the "vti timecreated" attribute in that file is set to the current time, to indicate the time at which the web was created.
  • the attribute "vti extenderversion" is set to the version number of the server extension program.
  • Web server specific access control information about the new web is also created through internal routines of the server extension program that are specific to the type of web server. These internal routines are server-specific because server access control information is stored in different ways for different servers.
  • mappings in the web server configuration information for the new executable directories associated with this web are then created. This is done through internal routines of the server extension program that are specific to the type of web server, because server configuration information is stored in different ways for different servers. These mappings direct the server to map a particular set of URLs (those with a common prefix of the URL for this web) to the physical location of the web content files on the server machine (the web content directory). For example, when creating a web on a NCSA server, the server extensions use a NCSA specific internal routine to add the lines listed in Table III to the NCSA server configuration file " srm.conf " . These lines indicate that four directories on the sever machine are marked as containing CGI programs or scripts, and furthermore defines the URLs to be used when accessing these programs or scripts.
  • An initially empty area for private content of the web An initially empty text index for the new web.
  • an initially empty document dependency database for the ne web and an initially empty task list of unfinished tasks for the new web are then all created.
  • the name of the new web is then added to the file that stores the list of all webs associated with this server.
  • An area for CGI programs and scripts that implement the server extensions of this invention is created and any necessary CGI programs and scripts are copied to this area.
  • an area for custom CGI programs and scripts that are created by an author is also created.
  • File system access permissions on each file in the web are then set to complete this operation.
  • an HTML document containing either a status message containing the web meta information for the newly created web. or an error message is then constructed.
  • This document is returned as the response to the server program which in turn sends it to client communication interface module as described earlier.
  • the client authoring tool calls the ListServices API procedure to retrieve a list of all web on the server machine. If necessary, this procedure initiates a SERVER VERSION transaction to retrieve the version number of the server extension programs in order to check compatibility between the client author program and the server extension programs. The procedure then initiates a LIST SERVICES transaction to retrieve the list of all webs on the server machine.
  • the server extension program on the server receives a LIST SERVICES transaction
  • the program performs the following tasks.
  • the file that stores a list of all webs associated with this server is read to obtain the list.
  • An HTML document containing either a status message with the list of webs, or an error message is then constructed.
  • the HTML list format can be used with each web name as a list item.
  • the constructed HTML document is then returned as the response to the server program which in turn sends it to the client communication interface module as described earlier.
  • the client authoring tool calls the ListDocuments API procedure to retrieve a list of all documents in a given web on the server machine, and to retrieve for each document a list of link from that document to other documents.
  • the procedure initiates a LIST DOCUMENTS transaction to retrieve the list of all documents in the given web on the server machine, and to retrieve for each document a list of links from that document to other documents.
  • the server extension program on the server receives a LIST DOCUMENTS transaction, the program performs the following tasks. Starting with the content directory for this web. a recursive tree traversal algorithm is used to identify each document in the file hierarchy for this web. These documents may be HTML documents, text documents, or images. For non-HTML documents, such as images, a document record is formatted containing the name of the document.
  • the document meta information file associated with this document is located. This file is read to get the list of links from this document to other documents.
  • the attribute "vti cachedlinkinfo " is used to obtain the list of links. If the list of links is unavailable or out-of date, then the list of links may be computed by parsing the HTML document.
  • a document record for this document is then formatted which contains the name of the document and a list o included documents or links to other documents.
  • An HTML document containing either a status message with all of the document records, or an error message, is then constructed. This document is returned as the response to the server program which in turn sends it to the client communication interface module as described earlier.
  • the client authoring tool calls the SetServiceMetainfo API procedure to modify the meta information about a web that is stored on the server machine. The procedure initiates a
  • the server extension program locates the web meta information file associated with this web.
  • the web meta information is stored in the file "service. cnf in the private configuration subdirectory of the web content directory.
  • the contents of the web meta information file are modified to reflect the new attribute key value pairs contained in the SET SERVICE METAINFO transaction request.
  • An HTML document is constructed, containing either a status message with the web meta-information. or a error message. This document is returned as the response to the server program which in turn sends it to the client communication interface module as described earlier.
  • the client authoring tool calls the SetDocumentMetainfo API procedure to modify the meta information about a document that is stored on the server machine.
  • the procedure initiates a SET DOCUMENT METAINFO transaction to modify the meta information about a document that is stored on the server machine.
  • the server extension program locates the document meta information file associated with the saved document, as described earlier.
  • the contents of the document meta information file are modified to reflect the new attribute ke value pairs contained in the SET DOCUMENT METAINFO transaction request.
  • An HTML document is then constructed containing either a status message with the document meta- information, or an error message. This document is returned as the response to the server program which in turn sends it to the client communication interface module as described earlier.
  • the client communications interface module In response to some calls made by the client authoring tool, the client communications interface module initiates a SERVER VERSION transaction to identify the version of the server program with which it is communicating on the server machine.
  • the server extension program locates the server version information, such as shown in Fig. 6C.
  • An HTML document is then constructed containing either a status message with the server version information, or an error message. This document is returned as the response to the server program which in turn sends it to the client communication interface module as described earlier.
  • One of the advantages of this invention is that it allows client server authoring operations for a web. in a way which is independent of the particular server machine hardware or operating system software, and which is also independent of the HTTP server program implementation.
  • the independence with respect to server platform and server program is achieved through the us of primarily four techniques.
  • First, standard techniques may be used for writing portable software that may then be compiled on several different platforms.
  • use of the CGI protocol as a means of invoking the server extensions from the HTTP server program, and as a means for passing parameter information from the server to the server extensions provides additional server program independence.
  • the data content carried by the HTTP protocol messages do not contain any platform or server dependent information.
  • this system can be implemented and used with ordinary HTTP server programs without custom modification, as long as the server supports the CGI standard.
  • Another advantage of this system is that the client authoring tool does not need to map the file name space of the server to its own file name space.
  • This arrangement is particularly advantageous in large networks, such as the Internet, where there may be many authors of many on-line services on many servers.
  • the ability to remotely author documents is made easier and eliminates the need for complex file systems like a network file system.
  • Another advantage of this system is that the ability to store files on the server is made possible in a manner which is transparent to usage by a Web browser.
  • the server By using a server extension program to control processing of messages, the server also need not be modified.
  • the server is simply configured to recognize the server extension program, thus allowing easy installation.
  • the functionality of the server extension program might be embedded in the web server itself and need not be as an implemented CGI script.
  • the HTTP communication protocol could also be used, using "get” and “put” commands in that protocol.
  • Other protocols using messages communicated over TCP/IP connections are also possible.
  • a mix of such protocols may also be used to perform retrieval or storage functions.
  • a service author will keep local copies of document objects of an on-line service so l() that only a remote storage function is used.
  • systems in which a client program modifies and stores documents and programs on the server using protocols over a TCP/IP connection between the client and the server are also within the scope of the invention.
  • the client and server may be connected by the Internet, or a private local or wide area network or may be on the same machine.
  • the client authoring tool may be configured to communicate only

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Health & Medical Sciences (AREA)
  • Artificial Intelligence (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Computational Linguistics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)
EP96908850A 1995-03-17 1996-03-18 Rechnersystem und verfahren zur herstellung und erhaltung von online-diensten Ceased EP0815518A1 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US406360 1995-03-17
US08/406,360 US5732219A (en) 1995-03-17 1995-03-17 Computer system and computer-implemented process for remote editing of computer files
US566281 1995-12-01
US08/566,281 US5793966A (en) 1995-12-01 1995-12-01 Computer system and computer-implemented process for creation and maintenance of online services
PCT/US1996/003654 WO1996029664A1 (en) 1995-03-17 1996-03-18 Computer system and computer-implemented process for creation and maintenance of on-line services

Publications (1)

Publication Number Publication Date
EP0815518A1 true EP0815518A1 (de) 1998-01-07

Family

ID=27019486

Family Applications (2)

Application Number Title Priority Date Filing Date
EP96908850A Ceased EP0815518A1 (de) 1995-03-17 1996-03-18 Rechnersystem und verfahren zur herstellung und erhaltung von online-diensten
EP96909744A Ceased EP0815519A1 (de) 1995-03-17 1996-03-18 Rechnersystem und verfahren zur ferneditierung von rechnerdaten

Family Applications After (1)

Application Number Title Priority Date Filing Date
EP96909744A Ceased EP0815519A1 (de) 1995-03-17 1996-03-18 Rechnersystem und verfahren zur ferneditierung von rechnerdaten

Country Status (3)

Country Link
EP (2) EP0815518A1 (de)
JP (2) JPH11502346A (de)
WO (2) WO1996029664A1 (de)

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6564321B2 (en) 1995-04-28 2003-05-13 Bobo Ii Charles R Systems and methods for storing, delivering, and managing messages
WO1998021672A2 (en) * 1996-11-15 1998-05-22 Inergy Online, Inc. Remote communication, information management, and home page authoring system
JP3927246B2 (ja) * 1997-02-19 2007-06-06 株式会社 デジパーク 仮想空間情報処理装置
US5937404A (en) * 1997-04-23 1999-08-10 Appaloosa Interactive Corporation Apparatus for bleaching a de-activated link in a web page of any distinguishing color or feature representing an active link
DE19717167A1 (de) * 1997-04-23 1998-10-29 Ibm Webbrowser-basiertes Konferenzsystem
US7315386B1 (en) 1997-06-30 2008-01-01 Fujifilm Corporation Image communication system and method
JP3544457B2 (ja) * 1997-08-22 2004-07-21 インターナショナル・ビジネス・マシーンズ・コーポレーション 電子メール又はエージェントを利用してクライアント上でguiを作成する方法及び装置、そのためのプログラムを記録した記録媒体
US6157936A (en) * 1997-09-30 2000-12-05 Unisys Corp. Method for extending the hypertext markup language (HTML) to support a graphical user interface control presentation
US20060193278A1 (en) 1997-10-15 2006-08-31 Wolfgang Theimer Mobile telephone for Internet applications
US6886130B1 (en) 1997-11-26 2005-04-26 International Business Machines Corporation Compiled structure for efficient operation of distributed hypertext
US6230168B1 (en) 1997-11-26 2001-05-08 International Business Machines Corp. Method for automatically constructing contexts in a hypertext collection
US5991713A (en) * 1997-11-26 1999-11-23 International Business Machines Corp. Efficient method for compressing, storing, searching and transmitting natural language text
US6178439B1 (en) * 1997-12-23 2001-01-23 British Telecommunications Public Limited Company HTTP session control
WO2000051029A2 (en) * 1999-02-26 2000-08-31 Atabok, Inc. Method and apparatus for delivering electronic data through a proxy server
DE19922118A1 (de) * 1999-05-12 2000-11-23 Oce Printing Systems Gmbh Netzwerk, Interpreter für ein derartiges Netzwerk und Verfahren zum Betreiben eines Netzwerkes
KR100326425B1 (ko) * 1999-07-28 2002-02-28 최재학 홈페이지 제작 방법
JP2002149546A (ja) * 2000-11-06 2002-05-24 Enshiyou Honsha:Kk バナー広告システムおよびバナー広告の管理方法
US20020083182A1 (en) * 2000-12-18 2002-06-27 Alvarado Juan C. Real-time streamed data download system and method
US7437429B2 (en) * 2001-02-13 2008-10-14 Microsoft Corporation System and method for providing transparent access to distributed authoring and versioning files including encrypted files
JP2002259340A (ja) * 2001-03-06 2002-09-13 Hitachi Software Eng Co Ltd サーバ回収型コンテンツ更新方法及びコンテンツ更新システム
JP2004070619A (ja) * 2002-08-06 2004-03-04 Tdk Corp ウェブページのアップロードシステム、コンピュータプログラムおよび記録媒体
US7383586B2 (en) 2003-01-17 2008-06-03 Microsoft Corporation File system operation and digital rights management (DRM)
US8028204B2 (en) 2009-03-20 2011-09-27 Xerox Corporation Method and system for maintenance of a data-processing apparatus

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO9629664A1 *

Also Published As

Publication number Publication date
EP0815519A1 (de) 1998-01-07
JPH11502346A (ja) 1999-02-23
WO1996029663A1 (en) 1996-09-26
JP4306797B2 (ja) 2009-08-05
WO1996029664A1 (en) 1996-09-26
JPH11507148A (ja) 1999-06-22

Similar Documents

Publication Publication Date Title
US5793966A (en) Computer system and computer-implemented process for creation and maintenance of online services
US5732219A (en) Computer system and computer-implemented process for remote editing of computer files
US5890171A (en) Computer system and computer-implemented method for interpreting hypertext links in a document when including the document within another document
WO1996029664A1 (en) Computer system and computer-implemented process for creation and maintenance of on-line services
US7168034B2 (en) Method for promoting contextual information to display pages containing hyperlinks
US6189019B1 (en) Computer system and computer-implemented process for presenting document connectivity
US6275829B1 (en) Representing a graphic image on a web page with a thumbnail-sized image
US6456308B1 (en) Embedded web server
US5973696A (en) Embedded web server
US6571245B2 (en) Virtual desktop in a computer network
US6421716B1 (en) System for generating context-sensitive hierarchically ordered document service menus
JP4594586B2 (ja) ネットワーク・クライアントにおいて情報を処理するための方法およびシステム
US7269664B2 (en) Network portal system and methods
US6578078B1 (en) Method for preserving referential integrity within web sites
EP0747843B1 (de) Verfahren zur Ausführung von Anträgen eines Netzbrowsers
US7406664B1 (en) System for integrating HTML Web site views into application file dialogs
US20020078102A1 (en) Method and system for customized modification and presentation of remotely saved web content
US20050198569A1 (en) Method and apparatus for providing a graphical user interface for creating and editing a mapping of a first structural description to a second structural description
US20020065849A1 (en) Method and system for integrating network-based functionality into productivity applications employing word processing documents
US20070239726A1 (en) Systems and methods of transforming data for web communities and web applications
US20030083952A1 (en) Web-based imaging service providing the ability to specify a charge-back account
EP0918424A2 (de) Automatische Verbindung von vorbestimmten Benutzerdaten mit Abfrageeingabefeldern
JPH11316719A (ja) ドキュメントの作成を援助する方法およびシステム
KR19990044881A (ko) 전자 메시지를 보관 및 액세스하기 위한 데이터프로세싱 시스템 및 방법
JP2000207421A (ja) ハイパ―リンクを使用して文書を検索するための方法及びシステム

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 19971010

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): DE FR GB

17Q First examination report despatched

Effective date: 20040216

APBK Appeal reference recorded

Free format text: ORIGINAL CODE: EPIDOSNREFNE

APBN Date of receipt of notice of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA2E

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

APAF Appeal reference modified

Free format text: ORIGINAL CODE: EPIDOSCREFNE

APBT Appeal procedure closed

Free format text: ORIGINAL CODE: EPIDOSNNOA9E

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20120604