Dynamic Documents Extensibility and
`Adaptability in the WWW
`
`Frans IKaashoek Tom Pinckney and Joshua
`MIT Laboratory for Computer Science
`545 Technology Square
`Cambridge MA 02139 USA
`
`Tauber
`
`kaashoek pinckney osh lcs .mit edu
`
`September 15 1994
`
`Abstract
`
`We propose dynamic documents as an approach to extending and customizing the
`Mosaic interface to the WWW Mosaic implements rigid policies that limit
`the range of
`environments in which it can function Dynamic documents overcome this problem by
`their own policies Dynamic documents are programs
`allowing documents to implement
`executed
`Mosaic
`they are implemented as Tcl
`document
`client
`to generate
`at
`scripts We have modified the NCSA Mosaic
`to use modified Tcl
`interpreter
`retrieves The interpreter is designed to execute only
`to run the dynamic documents it
`those commands that do not violate safety
`We have used dynamic documents
`an adaptable Mosaic client
`to configure
`to
`mobile environment
`The use of dynamic documents allows adaptable clients to adjust
`variety of mobile platforms and network environments We have used the adap
`to
`tive client and dynamic documents
`to build an adaptive e-mail browser that employs
`caching and prefetching strategies Both the browser and the dis
`application-specific
`played e-mail messages are dynamically customized to the computing environment
`in
`which they run
`
`client
`
`Introduction
`
`Information retrieval will be one of the driving applications of computing Popular informa
`tools need to be adaptable to many environments and platforms in order to
`tion retrieval
`allow users to have information at their fingertips Recently the World-Wide Web WWW
`and NCSA Mosaic have become extremely popular information retrieval
`As cur
`tools
`rently designed Mosaics fixed policies and fixed interfaces prevent
`from easily incorporat
`ing new applications or running on computing platforms differing from the high-performance
`workstations connected to high-bandwidth networks for which Mosaic was designed
`
`it
`
`Petitioner IBM – Ex. 1049, p. 1
`
`

`
`Currently Mosaic implements rigid policies for fetching displaying and interacting with
`documents We propose to allow documents
`to set their own policies by using information
`the client hardware and user preferences The single set of policies
`that Mosaic provides about
`tuned to the high-performance workstation environment would then no longer constrain the
`use of Mosaic in other environments For example Mosaic currently automatically displays
`all HTML documents it
`query In the environment for which Mosaic
`receives in response to
`was developed this policy performs adequately However on another platformfor instance
`mobile wirelessly-networked computerthis display policy could easily overload the network
`and use all
`the limited screen space
`
`number of groups are addressing this problem by extending the HyperText Transfer Proto
`col HTTP e.g Common Gateway Interface the HyperText Mark-up Language HTML
`or by introducing new protocols e.g HTTP
`18 Unfortunately since protocols
`function as standards for information exchange they cannot be easily modified We address
`this inflexibility by introducing dynamic documents Dynamic documents are programs ex
`ecuted by an adaptive WWW client
`to the client The
`in order to produce information local
`most common use of dynamic documents is to generate HTML that
`is displayed to the user
`to extend and to adapt Mosaic Section
`describes the use of dynamic documents
`Section
`2.1 describes of the implementation of dynamic documents Section
`describes an adaptive
`Web client that supports dynamic documents caching and prefetching as well as how these
`features are used in an adaptive e-mail browser Finally we describe related work and
`conclude
`
`Dynamic Documents
`
`We propose dynamic documents as an approach to extending and adapting WWW/Mosaic
`in exactly the same manner
`Dynamic documents are programs fetched by Mosaic client
`as any other MIME Multipurpose Internet Mail Extensions object
`dynamic document
`the document and
`may contain both the data of
`set of scripts to control
`its presentation
`number of actions
`Execution of
`dynamic document may cause the client
`to perform
`final presentation to the user other documents may be fetched
`to generate
`new HTML may be generated information local to the client may accessed or an entirely
`separate interface may be generated Thus dynamic documents add
`great deal of flexibility
`to Mosaic Dynamic documents
`can be used to extend many Mosaic policies however
`paper focuses on three main areas information retrieval
`information display and interface
`processing
`
`in order
`
`this
`
`information retrieval policies rely on some form of
`All current proposals for altering client
`built-in policy These policies control when and how Mosaic retrieves and retains documents
`In contrast dynamic documents allow document authors to determine the retrieval policy
`case-by-case basis For example in Sections 3.1 and 3.2 we discuss adding client-side
`on
`caching and prefetching to Mosaic The caching and prefetching modules do not
`document
`have to use only one global policy Flushing invalidating and prefetching policies can work
`completely correctly and apply document-specific
`knowledge to their decisions
`
`The choice of which information to display is closely linked to the choice of which informa
`tion to retrieve While both choices are rigidly set
`in the standard Mosaic client dynamic
`
`Petitioner IBM – Ex. 1049, p. 2
`
`

`
`documents allow both information display and information retrieval to be customized at the
`few configuration options available but these are session-
`client Currently users may have
`specific and apply to all documents fetched Dynamic documents expand these choices and
`apply them to each fetched document
`individually For example if Mosaic is running on
`can select some core subset of
`mobile computer with
`dynamic document
`small screen
`information to display to the user while creating links to others Similarly if
`the network
`bandwidth is limited fetching large multi-media objects can be delayed and placed in the
`background while the user views more efficiently accessed information Any location infor
`mation available to the client can also be used to customize documents Without
`involving
`client with
`dynamic document might use location information to build
`the server
`page
`route to some
`with map indicating the computers current position and then compute
`Further as the clients operating parameters change e.g remain
`specified destination
`ing battery power or available network bandwidth the dynamic documents can alter their
`policies arbitrarily
`
`Mosaics interface processing capabilities are even more rigidly set than its information re
`trieval and display policies Currently only simple interface actions such as hyper-text
`link
`traversal and basic text searching are performed locally All other significant actions such
`forms and picture maps are performed on the server
`as processing the contents of fill-out
`This increases network bandwidth consumption and limits the scalability of the WWW In
`for creating new interface elements
`addition there is no support
`forced to use only what Mosaic provides
`We have lifted these restrictions through the use of dynamic documents All
`interface pro
`cessing can now be performed locally by Mosaic When
`form is completed when
`fill-out
`picture map is invoked or when
`key is pressed the client can process the same data locally
`to the server and like the server produce
`document
`that was previously sent
`result
`as
`
`document author
`
`is
`
`separate window
`Dynamic documents can even be used to create an arbitrary interface in
`Web interfaces are therefore no longer
`limited to what Mosaic can provide If documents
`forms they may create their own
`require more sophisticated
`input mechanisms or output
`Of course they may also invoke any of Mosaics built-in facilities For example
`dynamic
`separate window use Mosaic to fetch raw data from an HTTP server
`document
`can open
`and then create
`the data in the second window alternatively the dynamic
`3-D graph of
`window that
`user-interface while Mosaic was used
`document
`could simply provide
`ran
`to display data This allows the document designer to trade the greater network bandwidth
`and server cycles required to generate and ship the 3-D graphical representation for the client
`processing power required to generate it on the client
`
`In designing dynamic documents we decided to place
`the
`great deal of functionality at
`client The client must perform all document processing in addition to providing the Mosaic
`interface Placing processing on the client side is inherently more scalable than forcing all
`processing to be performed on the server We believe that
`this is the proper scheme since
`wireless network bandwidth is more scarce resource than mobile computing processing
`
`cycles
`
`Other arrangements of dynamic document
`functionality are possible For example dynamic
`documents that run on
`server could aid database queries Dynamic documents could even
`
`Petitioner IBM – Ex. 1049, p. 3
`
`

`
`database browsing document
`partition themselves across the client and server dynamically
`might decide that because of high server load and limited network bandwidth that queries
`should run on the server but all
`interface processing should be done on the client
`
`2.1
`
`Implementation Issues
`
`from
`
`Dynamic documents are implemented as Tcl scripts that are executed upon receipt
`WWW server Mosaic handles scripts as
`new MIME type Every document
`retrieved via
`HTTP has an associated MIME type that specifies the format of
`the data contained in the
`document For each format Mosaic has an interpreter either internal or external
`the data The viewer
`view of
`for dynamic documents
`is the Tcl
`capable of presenting
`
`that
`
`is
`
`interpreter
`
`Dynamic documents function by means of one or more callbacks
`procedure
`is invoked by
`provided by the dynamic document and registered with the Mosaic client
`particular condition is met For example when Mosaic needs to decide
`the client when
`callback may be invoked This callback is then
`what
`information to display to the user
`responsible for producing HTML that Mosaic displays
`
`callback is
`
`It
`
`they may be too powerful The
`One of the largest difficulties with dynamic documents is that
`variety and complexity of possible dynamic documents raises three issues safety portability
`and authoring One can address the issues of safety and portability by carefully selecting
`the scripting language in which to implement dynamic documents
`variety of scripting
`languages are available from which to choose We selected Tcl
`number of
`reasons
`for
`widely known safe version is available it
`is portable across Unix platforms
`Currently it
`is easily extended and through the use of Tic arbitrary X-based interfaces can be provided
`In addition the new Tcl/Tk project at Sun Microsystems promises to extend Tcl support to
`Macintosh and Windows environments provide
`secure execution environment and provide
`an interactive graphical user interface builder
`
`For our prototype we ensure safety by use of an interpreter
`limits the operations
`that
`down-loaded script may perform However we could easily switch to Safe-Tcl and thereby
`greatly decrease the chance that we have left any security holes in the language
`
`Since dynamic documents are so general we are investigating the possibility of assisting
`authors by automatically generating certain types of scripts For example it
`is possible to
`process standard HTML documents
`the amount of data initially
`into scripts that
`restrict
`transmitted to the client while fetching the rest in the background
`
`to Mosaic they do not entirely
`While dynamic documents add
`great deal of
`flexibility
`eliminate the need to extend protocols in Mosaic In order to add functionality to the client
`we need to define the primitives available to be invoked by dynamic documents
`These
`find out about and influence the
`primitives define the ways in which dynamic documents
`rest of the world While many primitives are possible we have decided only to address the
`information display and interface processing
`issues of flexibility
`in information retrieval
`Thus we provide functions to fetch information from HTTP servers to query parameters of
`the local computer and to perform user-interface actions as well as functions to control the
`
`Petitioner IBM – Ex. 1049, p. 4
`
`

`
`document cache We also need to specify which parts of Mosaic invoke which callbacks which
`parameters are passed in those callbacks and what side effects of
`the callbacks execution
`
`are expected
`
`An Adaptable WWW Client
`We have designed and implemented an adaptable WWW client based on NCSA Mosaic that
`supports dynamic documents Using dynamic documents we can configure the client to run
`number of platforms As an example we have used dynamic documents
`efficiently on
`to
`to mobile platform In particular we have adapted and extended the
`adapt our client
`fetching policies and user interface Additionally we have implemented
`clients document
`client side caching and prefetching as well as augmented Mosaic to generate traces of
`caching and prefetching behavior We have done this for two reasons First we hope to
`low-bandwidth networks
`interactive performance even in the presence of
`improve overall
`Second caching and prefetching are two areas where document specific policies can be much
`more effective than fixed global policies and so they provide good examples of
`the use of
`dynamic documents
`We have implemented the full
`of dynamic documents by modifying NCSA
`functionality
`Mosaic version 2.4 The client runs on
`stationary SPARCstation 10 running Solaris 1.0
`stationary computer we have been able to attract
`By running it on
`user community to
`traces on the usage of dynamic documents caching
`and
`the client and to collect
`test out
`prefetching We are using these traces to compare policies We are currently porting the
`1M-bit/s WaveLAN
`client to IBM ThinkPads running Linux and connected by
`
`its
`
`In this section we will discuss the implementation of caching and prefetching as well as
`an example applicationan adaptive e-mail browserthat employs dynamic documents to
`extend the interface of Mosaic and for application-controlled caching and prefetching
`
`3.1 Caching
`
`In Mosaic we have
`Caching is an effective technique to improve interactive performance
`the HTTP level
`the document
`document
`In wired environment
`implemented
`cache at
`it can be shared by an entire group
`proxy server so that
`cache is probably best stored at
`of users This architecture benefits from the locality due to the common interests and
`communications among users sharing the proxy server
`In contrast wireless connections
`often have low variable bandwidths that are less reliable It
`is unclear where to place
`proxy server for mobile user who may roam among several wireless connections
`Thus
`wireless environment can be better placed at the mobile computer itself We
`the cache in
`have chosen to make the cache persistent across
`from locality
`sessions in order to benefit
`between Mosaic sessions Additionally
`persistent cache may be pre-loaded for disconnected
`operation as in the Coda file system
`We have implemented caching at the HTTP level for ease of implementation When an HTTP
`is made for
`document
`is requested from
`is not currently cached the document
`that
`request
`the servers response is recorded Later when requests for
`the server and an exact copy of
`this Uniform Resource Locator URL are made the cached data is simply replayed as if
`
`it
`
`Petitioner IBM – Ex. 1049, p. 5
`
`

`
`When the document
`
`cache is full
`
`randomly picked
`
`had come from the network layer
`entry is discarded
`Since WWW servers do not provide callbacks stale cache data cannot be detected
`to maintain the correctness of cached data entries are cached for only
`attempt
`specific period of time The period of time used is an estimate of
`the time until
`the time between when
`modification The estimate is made by assuming that
`document
`is fetched from server and when it was last modified on that server is proportional
`to the
`the next modification will be made We provide dynamic documents with the
`time until
`additional ability to explicitly flush items from the cache This is the same basic method
`used by Glassman for the caching relay server
`
`To
`
`document-
`
`the next
`
`Several users have used our modified Mosaic on
`This global caching policy is adequate
`SPARCstation 10 during the three-week period of our trace and have experienced
`cache hit
`rate of about 40% The document
`cache is secondary to the standard Mosaic image cache
`and the Mosaic history cache Thus our caching statistics only reflect
`the load presented to
`cache All other references for images are first handled by the image cache
`our document
`hit ratio higher than that measured at the
`Thus the three caches may combine to display
`the document
`cache
`level of
`
`the global caching policy is not always correct At times stale data is used while
`However
`at other times data is needlessly fetched We solve this problem by allowing the cache to
`be controlled by dynamic documents
`callback with the
`can register
`dynamic document
`cache subsystem This callback will be used by Mosaic to determine if
`the cached entry is
`the entry is stale Mosaic will
`fetch the document
`fresh or stale If
`the callback returns that
`again from the server Otherwise the cached copy will be used Dynamic documents
`can
`to be fetched from the server the
`also invalidate particular entries forcing the documents
`next time they are referenced This arrangement allows dynamic documents to implement
`their own cache coherency protocols The adaptive e-mail browser described in Section 3.3
`below uses this mechanism to implement
`caching policy that only fetches data when it has
`on the server
`
`changed
`
`3.2 Prefetching
`
`To hide the latencies of slow wireless links we have implemented document prefetching
`Documents
`document
`copy of Mosaic performing
`are prefetched by forking
`fetch in
`the forked copy and loading the fetched document
`into the cache
`user
`requests
`document while prefetches are in progress the prefetches are suspended so that
`the full
`network bandwidth may be given to the users request After the users request completes
`The default prefetching strategy is to
`any suspended prefetches are allowed to continue
`prefetch documents based on the users Mosaic history list Every time
`page
`user visits
`Mosaic will begin prefetching all documents from the current page that
`the user has visited
`in the past
`
`If
`
`This implementation suffers from two distinct problems First
`forking an entire process
`merely to perform prefetching is expensive and inefficient Unfortunately since the current
`Unix implementations of Mosaic are single-threaded we are forced to use this approach
`
`Petitioner IBM – Ex. 1049, p. 6
`
`

`
`Future versions of Mosaic promise to lift
`
`this restriction and thus allow much more efficient
`
`prefetching
`
`Second and more importantly this strategy generates relatively few future cache hits while
`considerable amount of network bandwidth Our traces shows that on average
`consuming
`0.5 objects are prefetched for each object explicitly fetched by the user Of these prefetched
`objects only about 2% are actually used in the future The others just waste bandwidth
`and unnecessarily load servers This is clearly
`very poor policy
`We are investigating better strategies One alternative is to have the HTTP server monitor
`access patterns and then periodically augment documents with information that specifies
`what documents
`that client has requested
`client should prefetch given that
`document
`
`particular
`
`Dynamic documents allow global prefetching policies to be replaced by document-specific
`ones Prefetching is only effective when future access patterns can be determined Addi
`document
`tionally prefetching uses network bandwidth so the penalty for prefetching
`that
`is not needed may be large Since scripts have detailed document
`specific knowledge they
`are sometimes best equipped to make prefetching decisions Our adaptive e-mail browser
`provides its own prefetching strategy in order to prefetch only those documents which it
`knows are likely to be used in the near future This drastically reduces the number of ob
`the same time greatly increasing the chances
`that
`the prefetched
`jects prefetched while at
`is still unclear how prefetching in Mosaic will affect
`objects will be viewed.1 However
`other networked applications especially in
`wireless environment
`
`it
`
`3.3 An Adaptive E-mail Browser
`
`To investigate the potential of dynamic documents we have built an adaptive e-mail browser
`in which MIME-encoded e-mail
`Mosaic client Dynamic documents
`is accessed through
`in this application are used to dynamically generate the browser
`interface and views of
`mail messages In addition dynamic documents are used to implement application specific
`caching and prefetching strategies This application did not
`to the
`require any changes
`itself beyond those needed to support dynamic documents
`Mosaic client
`
`is organized as follows The browser
`The adaptive e-mail browser
`Tcl
`is implemented as
`scripts contained in dynamic documents retrieved from an HTTP server when the user opens
`the TJRL for the browser The dynamic documents then run on the mobile computer in order
`The browsers interface runs entirely on the client so
`to generate the browsers interface
`that button clicks and typing do not result in messages to the server Environment variables
`e.g screen size and network speed determine which parts of e-mail messages the browser
`retrieves At the client the browser then generates an HTML page for the message to display
`This setup dynamically moves the application interface from the server to the client As
`result we reduce the load on the server we reduce the network traffic between the client
`and server and we improve interactive performance
`
`The browser adapts to the screen size and to the network
`
`speed of
`
`the platform on which
`
`The browser only prefetches objects referenced
`
`in the currently displayed mail message
`
`Petitioner IBM – Ex. 1049, p. 7
`
`

`
`Figure With
`large screen and fast network the browser displays the messages with text
`separate window
`and graphics and has an elaborate user interface in
`
`it
`
`menu of URLs that point
`on the screen size it either displays
`runs Depending
`individual mail folders and messages or it generates more elaborate interface in
`second
`window that
`is more user friendly In addition messages adapt
`to screen size and network
`For example if
`the screen space is limited or the network
`speed slow the
`capabilities
`browser generates links to pieces of the message rather than actually fetching and displaying
`the data completely
`
`to
`
`and
`
`for
`
`shows
`
`Figures
`the browser
`
`illustrate how the browser adapts to different environments Figure
`platform with
`fast network
`big screen and
`In this configuration the
`separate window All text and GIF objects in
`browser presents
`interface in
`specialized
`the message are displayed while links are created to other objects e.g PostScript and other
`attached binary files Figure 2a shows how the browser adapts its interface to mobile
`It has only one window with more primitive interface based on the interface
`environment
`elements that Mosaic provides However as much interface processing as possible is done
`locally Figure 2b shows the display of mail message in the mobile configuration of the
`browser only the first
`in the message is displayed while links are created leading
`text object
`The important point about
`these figures
`in the message
`to all other objects contained
`the browser and mail messages adapt by using dynamic documents and client-side
`is that
`environment parameters No changes are needed to the mobile Mosaic client or the served
`dynamic documents
`
`If
`
`The browser employs caching and prefetching strategies based on the objects that are in
`the MIME standard for bundling and
`cluded in e-mail messages The browser understands
`normal RFC822 compliant mail mes
`transporting sequences of multi-media objects in
`the browser decides to create
`rather than including the object
`link to an object
`sage
`directly into the display the browser may prefetch some of
`the objects in the background
`In this way the fetching of potentially large
`the message
`while displaying other parts of
`objects e.g GIF or PostScript images can be overlapped with the user reading text The
`browser can do
`better job at prefetching than an application-independent
`scheme as the
`dynamic documents can take advantage of knowledge about
`the data being displayed e.g
`
`Petitioner IBM – Ex. 1049, p. 8
`
`

`
`The user
`and the message content
`Figure
`environment only text and links are displayed
`
`interface
`
`are adapted to
`
`mobile
`
`text GIF PostScript and of knowledge about how the application works
`
`Just as prefetching is under document control so is cache invalidation The browser controls
`which of
`its code and data pieces are cached and invalidated since only it has complete
`knowledge about when documents have changed For example the contents of different mail
`folders are cached and only invalidated when the user deletes mail from or incorporates new
`mail into the folder This is vastly better than relying on
`general caching and invalidation
`into Mosaic We have tried to quantify the performance improvement dynamic
`policy built
`normal user
`the caching and prefetching behavior
`documents provide by looking at
`that
`would generate We assume that
`the cache is warm which is
`reasonable assumption since
`frequently used application We also assume that
`the cache is persistent and mail is
`small number of new messages
`the e-mail browser will be to incorporate
`typical use of
`and then to view them Messages will be composed of at
`least text and maybe one or two
`attached images or PostScript objects We traced using the browser under such conditions
`the cache hit rates goes up to 60-70% from the previous 40% achieved using
`and found that
`global policy In addition the number of prefetches drops drastically corresponding
`to the
`number of
`images included in our sample e-mail messages all of which have
`fairly high
`chance of being used We do not
`intend this usage scenario and associated numbers to
`be taken as
`general characterization of dynamic-document-controlled caching or even of
`the e-mail browser
`is only the measurement of the effects of one policy on one example
`workload and is intended to be just an illustration of what
`
`is possible
`
`It
`
`Related Work
`
`new idea Many examples
`Using scripts for extending and customizing applications is not
`of this approach can be found
`Other
`relatively successful example is PostScript
`examples include the Andrew Mail system in which messages
`can contain fragments of
`the receiver This approach has been adopted for some more
`LISP code that are executed at
`safe subset of Tcl
`to do flexible mail processing Recent work
`
`recent mailers that defined
`
`uses scripting languages to implement
`
`intelligent agents
`
`Petitioner IBM – Ex. 1049, p. 9
`
`

`
`the WWW/Mosaic
`number of projects have been extending the applicability of
`In par
`ticular Houh et al implemented capabilities for shipping code from the client to the server
`an implementation of an HTTP
`to implement for example queries
`Mallery discusses
`in Common Lisp and argues for dynamically moving functionality from servers to
`server
`Our work differs from this work in that we propose
`client using fragments of Lisp code
`general approach for customizing and extending the WWW/Mosaic
`dynamic documents as
`and apply them to mobile computing environment
`
`number of groups have been working on Mosaic clients or other
`In the mobile arena
`this work focuses
`on the question what
`user interfaces for mobile computers Most of
`to run on the mobile computer and what part
`to run on
`the client
`part of
`stationary
`20 Landay and Kaufmann have used Scheme to ease the implementation of
`computer
`Our work currently assumes that clients have enough processing
`split user interface
`In the future we are planning to
`power to run the client completely on the mobile computer
`investigate how to implement dynamic documents on smaller mobile computers and use Tcl
`the interface which should work particularly well for Mosaic clients that are
`scripts to split
`being written using Tcl Schilit et al propose dynamic environment variables for customizing
`mobile applications while they are moving around this idea could easily be incorporated into
`dynamic documents
`
`the Coda
`Caching and prefetching have been used for mobile computers
`In particular
`19
`runs well on mobile computers
`project has worked on making
`file system that
`One of the potential advantages that dynamic documents offer is that
`they allow document-
`specific caching and prefetching Such domain knowledge might reduce bandwidth consump
`increase the number of cache hits Glassman reports on
`tion and might
`relay server that
`caches documents and gives
`detailed analysis of its performance
`
`Conclusions
`
`We have described dynamic documents mechanism for giving documents control of impor
`tant policy decisions in Mosaic Instead of relying on static policies built
`into Mosaic which
`that Mosaic displays we allow each document
`must suffice for every document
`to implement
`its own policy Among other things dynamic documents allow Mosaic to adapt easily to
`different computing environments
`We have implemented an adaptable WWW client based on Mosaic and for use in mo
`incorporates dynamic documents caching and prefetching We have
`that
`bile environment
`to implement mobile e-mail browser on this client
`used dynamic documents
`that grace
`fully adapts to mobile computing environments
`In addition the browser uses application-
`controlled caching and prefetching strategies
`
`Our initial
`the adaptable client on stationary computers for
`results based on the usage of
`three weeks indicate that dynamic documents are
`powerful approach to customizability
`and extensibility We have used application specific information with dynamic documents to
`customize information display and interface processing At the same time we dynamically
`move interface processing to the client decreasing network and server
`load and increasing
`scalability We have also been able to guarantee correctness of
`cache while dramatically
`the same time making prefetching feasible
`increasing its hit rate and at
`
`Petitioner IBM – Ex. 1049, p. 10
`
`

`
`Acknowledgments
`
`We thank David Gifford and James OToole for suggestions and ideas in the initial
`phase of
`this project We thank Dawson Engler for suggesting HTTP server annotation of documents
`to support prefetching We also thank Deborah
`Wallach Wilson Hsieh and Sanjay
`Ghemawat
`for their comments on versions of this paper
`
`About
`
`the Authors
`
`Frans Kaashoek is an assistant professor at M.I.T He is member of the Laboratory for
`Computer Science LCS and heads the Parallel and Distributed Operating Systems PDOS
`group His research interests include operating systems parallel and distributed comput
`and compilers
`ing networking protocols computer architecture programming languages
`number of systems that are
`He has published over 30 scientific papers and codeveloped
`commercially or publicly available In particular he is one of
`the principal designers of the
`Amoeba distributed operating system and the Orca distributed shared memory system
`graduate student at M.I.T and is member of the PDOS group at the
`Joshua
`Tauber
`LCS Before joining PDOS Mr Tauber was
`software engineer with the Matsushita Infor
`mation Technology Laboratory His principal
`interest is in distributed computing systems
`His most recent work focussed on system software for mobile computers He developed ap
`computer roams among various resource domains
`proaches to provide consistent service as
`Tom Pinckney is an undergraduate computer science student at M.I.T and is member of the
`Parallel and Distributed Operating System group He worked on
`novel storage system for
`workstations implemented dynamic documents for Mosaic and now spends his time dealing
`with classes
`
`is
`
`References
`
`Common Gateway Interface http//hoohoo.ncsa.uiuc.edu/cgi/intro.htmt
`
`HTTP
`for networked information http//info.cern.ch/hypertext/WWW/
`protocol
`Protoco/s/HTTP/HTTP2.htmL
`Language HTML
`HyperText Markup
`Mark Up/Mark Up htmL
`
`http //info cern ch/hypertext/WWW/
`
`MIME extensions for mail-enabled applications application/Safe-Tcl
`abled mail ftp //t humper be//core com/pub/nsb/st/safe-tc/.ps
`
`and multipart/en
`
`Mosaic http //www ncsa uluc eclu/SDC/S oftware/Mosaic/N CSA MosaicHome htmL
`
`Uniform Resource Locators
`
`http //info cern ch/hypertext/WWW/Acldressing/URL/
`
`Overview.htmL
`
`Intelligent agents issues CA CM 377 July 1994
`
`Luotonen H.F Nielsen and
`Berners-Lee
`Web Comm ACM 3787682 Aug 1994
`
`Caililiau
`
`Secret The World-Wide
`
`Petitioner IBM – Ex. 1049, p. 11
`
`

`
`David
`
`Crocker Standard for the format of ARPA internet
`
`text messages RFC 822
`
`Aug 1982
`
`caching re