Eolas Technologies Incorporated v. Adobe Systems Incorporated et al

Filing 1301

Opposed MOTION for Leave to File a Brief Re The Term "Browser Application" by Adobe Systems Incorporated, Amazon.com Inc., CDW Corporation, Google Inc., J.C. Penney Corporation, Inc., Staples, Inc., The Go Daddy Group, Inc., Yahoo! Inc., YouTube, LLC. (Attachments: # 1 Exhibit 1 - Defs Brief re the Term "Browser Application", # 2 Exhibit C to Brief - p353-meyrowitz82, # 3 Exhibit D to Brief - IRIS Hypermedia_Haan92, # 4 Exhibit E to Brief - ADBE0196713 Rowe92, # 5 Exhibit F to Brief - DBE0196715 Hindus93)(Wolff, Jason) (Additional attachment(s) added on 2/1/2012: # 6 Certificate of Authorization to File Under Seal, # 7 Text of Proposed Order) (mjc, ).

Download PDF
EXHIBIT D original "hypertext" to emphasize the linking of graphics, animation, sound, and video with textual information. Conklin's survey article [6) describes many of these systems. Some of the more recent systems are also described in the book by Nielsen [19]. _Ide t he subject of this article is Intermedia, one of these hypermedia systems. The authors were part of a team that developed Intermedia at Brown University's Institute for Research in Information and Scholarship (IRIS) between 1985 and 1990. Intennedia is distinct from many other hypermedia systems in that it is intended to model a multiuser hypermedia framework rather than a single hypermedia program. We did not want to create an isolated hypermedia "island~' where linking functionality was limited to connections between homogeneous data managed by a single program [16]. Our intention was to create a model for how hypermedia functionality should be handled at the system level, where linking would be available for all participating applications in much the same way that copying to and pasting from the clipboard facility is supported in the Macintosh and Microsoft Windows environments. lntermedia presents the user with a graphical file system browser (a functional equivalent of the Macintosh Finder); a set of directmanipulation editors for text, graphics, timelines, animations, and videodisc data; a browser for link information; a set of linguistic tools; and the ability to create and traverse links between any two selections in any document in the system. As will be explained in greater detail, information about selections (called anchors) and links between these selections is maintained in a management system database (DBMS). This separation of link data and document data is a distinctive feature of the Intermedia design. The lntermedia user begins by T All illustrations used in this article were created by Dynamic Diagrams. Inc. 38 January 19921Vo1.35. No.1/CO....UNICATIO_OFTH.ACM COMIIUNICATIONSOFTH.ACll/january 1992/Vo1.35. No.1 59 A was to Inte.llledia primallV' gOal ot= deillonst.ate that an ineeg.ated application envlllOnlllent bulle using obJect-o•• ented p.og.alll_ing eechniques Is ehe bese envlllOn_ent eo suppo.e lIypepllledla I=uncelonalley. running the Intermedia program from the Unix shell. The shell prompt is replaced by a graphical file system browser that presents documents organized in hierarchical folders. Documents and folders are manipulated using controls similar to those found in the Macintosh user interface. This view of the Intermedia document tree, which resides on a network server, is shared by all workstations on the local-area network. Color slides 1-6 are screen displays showing a user working with an lntermedia collection of nearly 600 documents about various NASA programs. As Yankelovich et al. have already stated, "Intermedia is both an author's tool and a reader's tool. The system, in fact, makes no distinction between types of users, provided they have appropriate access rights to the material they wish to edit, explore, or annotate. Creating new materials and making and following links are all integrated into a single seamless, multiuser environment" [26]. Each Intermedia document opens in its own window and any document can be edited by any user with appropriate privileges. In addition to the usual features offered by directmanipulation text and graphic editors, Intermedia users can create and follow links between selections in any document presented by the file browser. This link creation and browsing is shared by all parts of the user environment. Again we quote from [26]: In an effort to fit the link- 40 making process into a conceptual model already familiar to users, the act of making links between Intermedia documents was modeled as closely as possible on the Smalltalkl Macintosh copy/paste paradigm [10]. If links are to be made frequently, they must be a seamless part of the user interface. In any document, users can specify a selection region and choose the Start Link command from the menu. In any other document, regardless of type, users can define another selection region and choose . . . the Complete Link commands. To achieve these effects, however, we did not wish to alter an existing operating system or create a new one. We did, in fact, create a hypermedia program running within the Unix operating system to achieve the desired level of integration among different editors. To model how hypermedia would look when integrated at the system level, we created a single application that appears to the user as though it is the entire desktop environment. As we describe in subsection "Integration of Hypermedia into the Desktop," we believe our strategy can be used as a model for integrating hypermedia into a multi program computing environment. It is not our intention to provide a detailed summary of the features of Intermedia, as this has been done in a number of previous papers. The architecture was first described in [15]. The philosophy of "seamless integration" among application editors found in all ver- sions of Intermedia and the objectoriented nature of the software development effort are detailed in [26]. Additional features have been described in a number of papers over the past few years. These include features to support temporal data types described in (3, 13, 20]; the integration of morphological services and full-text retrieval into this hypermedia framework described in [7]; extensions to support group annotation of documents described in [4]; and the ability to replicate template structures of linked documents described in [5]. The purpose of this article is to focus on those unique features of the software architecture not previously discussed. We will describe the underlying architecture that made all of Intermedia's hypermedia functionality possible. The software architecture described in this article is that found in Intermedia 4.0, completed in August 1990. We have chosen the name IRIS Hypermedia Seroices to describe those parts of Intermedia which make the hypermedia functionality possible. The Intermedia editors, which are responsible for manipulating the content of their own documents, are the surface layer of a complex system. Each of these editors inherits functionality from the IRIS Hypermedia Services to support hypermedia capabilities. The overall architecture of the IRIS Hypermedia Services is shown in Figure 1. The Intermedia system appears to the Unix operating system as two processes. The Intermedia process is the end-user applica- January 1992fVo1.35, No.1 fCOMMUNICATIONS OF TN. ACM In orel•• to aeeOlllpllsh this kind oF Integration, it is bese to establish ove.al. poliCY goals and ellen to encapsulate as lIIuch ot= tile POlicy as possible In the obJect:-o.lelWed t=.alllewo.k eo be used by application develope... tion. This is built from four distinct layers. Starting from the user's point of view, the first layer consists of the file browser (or Finder), the five editors, each operating on its own document type, and the link browser (or Web View). These each share functionality defined in the second layer consisting of two major building blocks: one for text and one for graphic objects. Above this is the Intermedia Layer, a set of objects for managing hypermedia data that is shared by the building blocks. All these layers, in turn, are made from classes defined by MacApp, an object-oriented application framework developed by Apple Computer. Intermedia is a hypermedia application written to work on a specific version of Unix (AlUX 1.1) and a specific graphical user interface (Macintosh). The IRIS Hypermedia Services, however, embody those portions of the software that are independent of both operating system and graphical user interface. We feel this portion of the system is a useful model for the way hypermedia services could be migrated into the computing environment and deserves careful consideration by anyone currently designing software with hypermedia functionality. The IRIS Hypermedia Services is comprised of three parts. The first part consists of the objects defined in the Intermedia Layer and inherited by the end-user applications. The second part is the Link Client, a library that is bound with the Intermedia process. The third part is the Link Server, a library bound to a DBMS running as a separate process. The Link Client and Link Server communicate via Unix Domain sockets when the two processes are running on the same machine or via Internet sockets when they are running on separate machines. We will describe the IRIS Hypermedia Services in two stages. The first section of this article, "Features of Hypermedia Policy" describes the hypermedia policy supported throughout Intermedia. Here we will describe the end-user interactions, such as copy and paste of anchors and links, and the application-program responsibilities, such as menu handling, that define what "hypermedia" means in Intermedia. In the section "The Intermedia Mechanism" the mechanism used to support this hypermedia policy will be discussed. Here we will describe how the "hypermedia" information was managed and integrated with the application data. This will consist of a description of all three parts of the IRIS Hypermedia Services: Intermedia Layer, Link Client, and Link Server. After the IRIS Hypermedia Services have been described, this article will conclude with a discussion of five of the major issues to be explored in future hypermedia systems. Features of Hypermedia POliCY A primary goal of Intermedia was to demonstrate that an integrated COMMUNICATION80FTHIACM/January 1992/Vo1.35, No.1 application environment built using object-oriented programming techniques is the best environment to support hypermedia functionality. In order to accomplish this kind of integration, it is best to establish overall policy goals and then to encapsulate as much of the policy as possible in the object-oriented framework to be used by application developers. Our intention was to implement all general hypermedia policies at the framework level, leaving only applicationspecific details unresolved. In this way we assured maximum consistency among Intermedia applications. Anchor/Link Display, Highlighting and selection All Intermedia applications must support a persistent selection, called an anchor. Each anchor has an extent, the application-specific object to which the anchor refers. A link in Intermedia is a connection between any two anchors. All applications must support the display of a marker associated with each anchor. This marker has two states: linked and unlinked. A consistent visual appearance of this marker and how it is to be selected by the user is enforced as a matter of general policy in all Intermedia applications. It is up to the individual applications to determine how to "hook" the anchor to the appropriate document content and how to highlight the extent of the anchor. The selection of an object varies from application to application, depend- ., IRIS Hypermedia Services Architecture This schematic diagram Of Intermedia shows the layered architecture of the Intermedla system, with the Intermedla process on the left and the Link server process on the right. The two processes communicate over a socket connection. The raised and darkened layers Identify the portions of the architecture that constitute the IRIS Hypermedia Services. InterWord Document Dickens Blogrnphy ~:~~:~::::I:t ~ 9.~J~-1""-L,··~t-...,tf-'-tI""""!...,~:-'-'-!-'+II-l!.....~-i-'-.....'-:II.............. ! ' 1~'...,..1. . .·. -t~""""""-1Ip., ~.-".L.""_ . .!•. Paragraph Poem Subtitle Title fll.!Il!Il!Il l'IOroIal 11ii~§0! More ... I Charles, the first often children, was born In the same year. NicMlas Nic~1Jy gol underway in 1838, and continued through October 1839. in which year Dickens resigned as editor of Bentley ~ Miscellany. The first ~.b:~, J I[ - -- Bam8fJy Iltdge, which continued through November of that year. In 1842 he embarked on a vi$itto Canada and the United States In which he advocated international copyright(unscrupulous American publishers, in particular, were pirating his works) and the abolition of E!I slal/ety. His Amelfcan Notes, which created a furor in America(he commented unfavorably, for one thing, on the apparently universal-and, so far as Dickens was concerned, highly distasteful-American predileCtion for chewing tobacco and spilling out the juice), appeared In : Untitled II I I I To:ln~ s of Master HumPhleV~ Ooc};alllleared In 1840. andili'Je : : &CuiioSfrj S'Wp,-li'e-gun 'In 'Misi'erHUmontiV:contlnued; I l;3-' _. _ •• - - -, -- ,:WheriOIC'kenS commenced throu~h February 1841 ( New APPlY) Normel + InterMail Document !I)f3]I!U!l Cc:1 SUbject:lrequ~t for bibli09raPh~ 181 Salle me a copy ( Send) Nicole, Q ~ I jusl gol another request for the Hypermedia ,~i~~~ar~h~we should send !~$ ~~M·~!S~i~ .!r!l~ ~ ~~u~~~t,~ her.lfIease send a the version .. ---,s copy 10 this address in the liSt. <> 11O'2l QI E!I OctOber of that year, Mattin CINIzzlewif, part of which was .IGU• • .. Anchors In Text Both Interword (left) and InterMali (right) Inherft anchor behavior from the WOrd Building Block. In these text-based applications, an anchor conSists of any contiguous selection of characters. The anchor marker IS placed at the upper-left corner of the flrst character In the anchor and cannot be repositioned. The highlighting Of the anchor extent Is done with the dotted line Of the "marquee." o i Anchors In GraphiCs The remaining four Intermedla applications Inherft anchor behavior from the Graphics Building Block. The anchor'S extent Is Indicated by plaCing grey "handles" around the objects. In the case of the Interval tlmellne O. any time event or group of events can be an anchor. In Intervldeo . , any line or group Of lines defining a single frame or sequence of frames on a videodisc can be an anchor. Selections do not have to be contiguouS, but In bOth cases the anchor marker Is placed at the upper left Of the first Item selected and cannot be repositioned. In Intervldeo the order of selection determines the order In which the video clips are played when following a link to the anchor. Both InterDraw" and the InterPlay animation editor 0 allow any graphic object or combination of objects (any object In any frame of the animation In InterPlay) to be an anchor. While at creation the anchor marker appears at the upper left of the first obJect selected, It can be moved In these two applications In the same way as any other graphic object. 42 InterVal Document !i!!1.~_~iiii£!D~I't~.~ns]jTlm~e~lin!!J.~~!!i1i!!!i1i!~ _ Wntl$ autGIblographitaJ fragment Dlrlctl and acts in amateurUlealnCais eJ P~bllshl$ fin.af Cnrlstmas book., Haunte~ ~a."'id The Man,ln Dlcember Copper1lllld btgins running Da'll.tJ Capperftlld tlnls~lBs in November Foondsencledrlllhewe,UyHOU1:8hold Words iiei"n-s-wmiOn-eiip.-House."------"a fiifiiaiHouseliigiMlO appearmoiliii"i-S fieirHousee~isiji8ii;iT.-"1 Tou" ltiJy _ Collins. Augustu. Egg and Wilkie Retum.loEnglllld Glv..... lInlofmany publiC ..lading' ~O'" hhiO\lmwork"S. Januar~' 1992/VoI.35, No.l/COMMUMlCATIONS OPTH...eM ing on whether the object is text, graphics, or a cell in a table. The relative location of the anchor marker and the anchor extent is also a matter determined by the individual application. For example, I nterWord , the Intermedia text editor, places the anchor marker above the first character in the anchor extent. This marker moves with the anchor as the text is edited, but cannot be repositioned independently of the anchor extent. InterDraw, the graphics editor, and InterPlay, the animation editor, both initially place the marker at the upper-left corner of the first object selected and then allow the user to move the marker to any position in the document. Figures 2 and 3 illustrate how the marker is displayed in the various document types. Figure 2 depicts anchors in text-based applications; Figure 3 illustrates anchors in graphics-based applications. The relationship between selection of the anchor marker and selection of the anchor extent is a matter of general policy. Regardless of the relative position of the two, selecting the anchor marker constitutes selecting the anchor itself. This means that editing operations (e.g., cut or copy) on a selection which includes the anchor marker affects the anchor and link information. An editing operation on any portion of an anchor's extent not including the marker affects only the content of the anchor. InterVideo Document NEW Uh,eo Unls 2 <J[> 51., 1<11>1 Stop InterDraw Document !!!~~~I~'[~.'~M~IH~OgW.~U~IW~~"-~~~ c:::I So... Data Consistency It is a matter of general policy to keep document data and anchorl link data consistent at all times. The system must maintain integrity of the links and their respective endpoints in the face of editing operations on document names, locations, and contents. This is necessary to prevent "dangling links," (i.e., link references that point to nonexistent data or empty anchor references that point to data that was not saved). There are basically two mechanisms that have been used to maintain data consistency in hypertext systems. The system can store anchor and link information in the same files as the data, thereby ensuring that editing operations will affect them both. This mechanism is adequate for "read-only" hypertext collections where data consistency is fixed, and has been favored in many commercial systems. However, an editing operation that affects an anchor in one document will not necessarily affect all anchors in other documents linked to that anchor without some further consistency support. Unless some additional system-wide coordination is provided, editing operations as basic as changing a document's name and location will cause "dan- ,~~i~!t [E ·i'~iiJ Curr.M .,., .. The user can always clarify what portion of a document is "hooked" to a marker by choosing the marker and displaying its anchor extent. gling links." Alternatively, the anchor and link information and the document contents can be stored and managed in a separate but coordinated fashion. This is the mechanism used in Intermedia. We explain the strategy we used in the following two paragraphs, and in greater detail in the subsection "The Intermedia Layer." Intermedia stores document data in standard U nix files and anchorl link data in a separate database. The Intermedia document tree begins at a "root" on a local or mounted Unix file system such as "/intermedialdocuments" and consists of all documents in that file system created by Intermedia editors. The link and anchor information is stored separately in a DBMS. Collections of anchor and link data are partitioned into "webs." From the user's point of view, a web is a specific context in which anchors and links are created and stored. The user opens a web in order to browse and edit a specific collection of links. Each user can open only one web at a time. Responsibility for coordination of document data with anchor/link data resides in the IRIS Hypermedia Services. Editing operations performed by all applications and the Intermedia file browser pass through this layer of the framework. For example, the deletion of a document from the Intermedia file browser will cause the deletion o InterPlay Document New£UiIt II Current Line Widths flrrowheads lin. ../-- ,. .. 50lllngo fill leHt letkgroond vIt--8 ~ _ a---B 8----tI s.... =:J:tD r•• 5"'" I~::;~ I Dt> 1<11>1 COMMUNICATIONS OF THI ACMfJanuary 1992/VoI.35, No.1 43 and to that document throughout the database. Saving the web, that is saving the changes to the set of anchors and links displayed in the Web View, will cause the application editors to first save editing changes in all documents containing those anchors and links. If the user saves changes to documents but discards changes to the web, anchor and link information that had been cached in memory during the editing session is not written out to the database and remains unchanged. selection Handling It is a matter of policy that all applications manage persistent selections. This must be done by communicating with the IRIS Hypermedia Services, not by saving anchor information in the documents themselves. Each editor must support the ability to edit document data and keep track of the location and current state of the markers and anchor extents. The support for this policy varies from editor to editor. Menu Handling All commands used for editing links (create anchor, start link, complete link, etc.), displaying link properties (display anchor properties, display link properties), and browsing links (show anchor extent, follow, push, pulJ) are consistent across all Intermedia applications. All these commands are managed in the Intermedia Layer rather than by the individual applications and are presented in a pull-down menu shared by all editors. Editing AnchorIlink Objects It is a matter of policy that cut! copy/paste operations work in a similar fashion for both document data and anchorllink data. The copying or cutting of the anchor marker, not the data in the anchor extent, constitutes the copying or cutting of the anchor and any link data. Resizing of the anchor extent is supported in the same way that resizing or extending selections is supported. The undo and redo of editing operations involving anchors and links are also supported in a manner identical with other forms of document data. For example. InterWord, like all Intermedia editors, supports undo and redo of all edit operations in the "live" copy of the document maintained in memory between Save operations. This support is extended to cut! copy/paste of anchor information as well. It is possible to make a selection in one InterWord document that contains text and link markers, and cut that selection, thereby deleting the selected text and unlinking the selected markers. The user can then paste the selection into another document thereby inserting both the text and links. The changes in the Web View map for both documents will be reflected immediately. Undoing the cut operation will affect the "live" copy of the first document while undoing the paste operation will affect the "live" copy of the second document. Multiuser Access to Documents, Anchors, and Links Intermedia supports multiple users reading and annotating a single document, and only one user writing to a document at a time. While each user can have only a single web open at a time, any number of users on the same network can simultaneously open the same web and view the same documents, anchors, and links. The first user to edit the document content locks out all other users from editing the content until the document is closed. By annotation we mean the creation or modification of anchors and links as distinct from the creation or modification of document data. Because Intermedia stores anchor and link data in a separate database, we are able to support simultaneous annotation, allowing many users to make links to the same documents at the same time. Intermedia supports separate access rights for read, write, and annotate privileges on a per-document basis. This world of multiuser hypermedia running across local-area networks requires a policy establishing when changes to data by one user become available to all users. In Intermedia, all newly created anchors and links are local to the user's workstation until they are saved to disk. Changes made to open documents are not broadcast to other users. Intermedia does not update the view of anchors and links in any open document based on the actions of another user. Each user must close and reopen a document and associated web to see changes made by another user. Active Anchors To support editors that manipulate temporal data such as animation and motion video, Intermedia adopted the policy of active anchors [20]. Editors of temporal data support an action flag associated with each anchor. The temporal editors must examine the state of the action flag on the anchor when following a link to an animation or video document. Note that active anchors can also be used to execute a query or perform a sequence of actions defined in a script associated with the destination anchor. If the anchor's action flag is set, a follow into that anchor causes the application-specific action, such as running an animation, to occur. If the action flag is not set, following the link opens the document and highlights the anchor without performing the action. The content of the anchor can be viewed, edited, played, or executed using manual controls. Transfer of webs Sets of linked documents can be transferred from one Intermedia system to another using a canonical form of the link data described in [21]. This transfer functionality supports the selection from the Intermedia file browser of one or more file system folders (representing the document data) containing January 1992/Vo1.35, NO.l/COMMUNIc&TIONS OF TH. AeM one or more web documents (representing the link data). Though it is not specifically addressed in the Intermedia policy, we recognize that the interchange of hypermedia data between different hypermedia systems is an important issue. One of the authors of this article (Meyrowitz) participated in discussions which led to the Dexter Interchange Format (12], an abstract reference model for hypermedia data. Another author (Riley) participated in the planning process that has led to the proposed HyTime standard (ISO/IEC DIS 10744) [11,18], a markup language for representing multimedia, hypermedia, and time/space-based documents. Although lntermedia's transfer policy was originally designed to support the exchange of data between Intermedia users, Killough has shown it to be viable as an interchange format between Intermedia and other hypertext systems as well [14]. This was accomplished by converting the lntermedia interchange data into the Dexter Interchange Format, and from this data generating the format used by the KMS hypertext system [1]. One of the design criteria for HyTime is that it be Dexter-compliant. This suggests it should be possible to convert the Intermedia interchange format into a HyTime format as well. The Intermedla Mechanism In Intermedia, the hypermedia policies are encapsulated in a mechanism that has two major components: the Intermedia Layer and the Link Engine. The Intermedia Layer supports all live data manipulation while the Link Engine supports the storage and retrieval of persistent link data. The storage and retrieval of document data is managed elsewhere in the Intermedia process and is not discussed in this article. The Intermedia Layer is implemented as a set of classes that inherit from the MacApp application framework as well as newly defined classes that model anchors, links, and webs. The Link Engine is com- posed of the Link Client, the Link Server, and a DBMS. The Link Client is a class with which the Intermedia Layer communicates. The Link Client in turn communicates with the Link Server. The Link Server is a generalized class communicating data requests to a DBMS. A schematic diagram of the three parts of the IRIS Hypermedia Services and their relation to the other parts of the I ntermedia architecture is shown in Figure 1. This shows how the Intermedia Layer and Link Client are bound in the Intermedia process and the Link Server and DBMS are bound in a separate process. The Intermedia Layer The Intermedia Layer consists of extensions to the MacApp framework to support linking capabilities. Included in this layer is a data model class (IntDoc) which handles reading anchor/link data associated with a document. A data view class (IntView) provides a set of abstract methods for the display of anchor markers and for highlighting anchor extents. Cut, copy, and paste operations are supported by the IntClipboard class. Activation of and response to hypermedia operations in the menus (create anchor, start link, complete link, etc.) is supported by methods of the IntSelection class. Within this object-oriented application framework, we created application building blocks that inherit some of the functionality from the Intermedia Layer and override some of its abstract methods. For example, the Graphics Building Block subclasses the IntView class to handle graphic object selection and highlighting of anchor extent shown in Figure 4. This, in turn, is used in both the InterDraw and InterPlay editors. The Intermedia Layer also contains a Web class. When a web is opened, an instance of the class, the Web Object, is created. This object contains a live copy of all newly created and edited anchor and link COMMUNICATIONS OF THE ACMIJanuary 1992/VoI.35, No.1 data on a per-web basis. This live data is merged by the Intermedia Layer with the current data from the link database. It is here that the policy of data consistency is enforced. The document and link database are synchronized by forcing documents to be saved before the data of the Web Object can be saved. For example, a user has made a link between a selection in an existing document and a selection in a newly created document. To save this link, the user saves the Web View, which first saves the documents that have been edited before saving the anchor and link information in the web. This ensures that all anchor and link information in the link database is synchronized with the current saved state of each document. Consistency is also maintained in operations that affect anchor and link information in unopened webs. For example, when a document is deleted, all links containing anchors in that document are removed from the database. The delete operation will affect links in any web in the database. In addition, a user can edit a portion of a document that is all or part of an anchor extent in an unopened web. The effect this has on the anchor extent is resolved when the edited document and the web containing that anchor are opened. Intermedia provides an orientation feature called the Web View which contains a list of the documents viewed by the user and a map of documents linked to the currently active window. The Web View rationale and functionality is described in [23]. The link map in the Web View relies on the Web Object for its information. All Intermedia editors read in anchor information from the link database and correlate this to the application data in each document at the time the document is opened. Subsequent changes in the Web Object are displayed in the live copy of the document and Web View on each user's workstation, but are not propagated to the live copy of the 45 same documents elsewhere on the network. The Link Engine link, and document transactions to the Link Engine and reads that information from the Link Engine via the methods of the Link Client class. These methods, which constitute Intermedia's linking protocol, The Web Object of the Intermedia Layer communicates the anchor, Application Framework Architecture The class hierarchy of Intermedla's application framework Is illustrated In part. The View method In the MacApp layer Is subclassed by Intvlew In the Intermedla layer where several abstract methodS to manage the display of anchors and markers are added. These methods are then defined In the gVlew and tVlew classes of the oraphlcs and Word Building Blocks. In addition to the subclasses from MaCApp, the Intermedla layer adds new classes for Anchor, Link, and Web, shown on the right. Client/Server/DBMS Flow of Control The OetAnchorLlst method In the web class of the Intermedla Layer (see Figure 4) requests a list of all anchors In a document. This request Is passed to the AnchorGetFirst method In the Link Client o. This passes the request over the socket connection to the abstract method AnchorGetUst In the Link Server 8 which Is defined In Link Ctree method AnchorGetL/st •. This method translates the request Into a series of low-level DBMS operations (REDVREC), requesting all anchors with a specific document 10, returning the anchors and repeating until done O. This list of all anchors Is cached In the Link Server" and then returned to the AnchoroetNext method In the Link Client CD one at a time across the socket. ••GU• • e. Link Engine Data Model This shows the six major relations In the Link Engine data mOdel. The primary key for each relation Is raised to Illustrate how the data Is connected. Note that the DOcument 10 JOins the Document relation to the Document Lock, Link, and Anchor relations. The Anchor 10 Joins the Anchor, An· chor View, Anchor Application, and Link relations. The Link Is de· fined as pairs of Anchor and DOCument IDS. The web Is defined as a field of the Anchor and LInk relations. 46 January 1992/VoI.35, No.IICO .... UNICATION.OFTH.AC.. support establishment of connections over sockets, opening and dosing of databases, and a set of operations for manipulating document, link, and anchor data. An example of how this data is communicated will illustrate the way different parts of the architecture share in the hypermedia mechanism. When the Intermedia process is initialized, the Link Client establishes a connection to the Link Server and opens the link database. When the Intermedia user opens a web document, the Web Object in the Intermedia Layer requests all the corresponding web information from the Link Engine. The Web Object has a method called GetAnchorList (shown in the Web class in Figure 4) which returns a list of all anchors and links for a document each time a document is opened. When the user opens a document, this request is communicated to the Link Client, which passes the request to the Link Server over the socket, using a predefined set of byte codes. The Link Server accepts these byte-coded messages and then performs a series of operations on the database to retrieve all anchor and link information for that document by making calls to a DBMS, in this case the commercially available C- Tree [9]. The information is then returned to the Intermedia Layer along the same communication path. This is shown in Figure 5, which follows the AnchorGetFirst method from the Link Client, to the Link Server, to the DBMS, that performs the low-level operation to read the anchor data for the specified document ID from the database. The resultant list of all anchors is cached by the Link Server. This list is then accessed one anchor at a time by the Link Client through the AnchorGetNext method. The Intermedia Layer then passes the application-specifIc anchor information to the document editor by invoking abstract methods that the document editor has overridden. These methods then display a marker for each anchor and hook the anchor to the appropriate data in the document. The Link Engine can be described in terms of a data model and the operations that can be performed on that data model. Data Model The persistent link information is organized in five major relations: document, anchor, anchor view, anchor application, and link. A schematic diagram of these relations is found in Figure 6. Document Relations. The document relation matches a unique document identifier with the document name, Unix path and the basic properties such as creator, creation time, modifier, and modification time. The primary index for this relation is the unique document identifier to support efficient retrieval and reliable operation independent of changes in document name and location. A secondary relation is the document lock relation which maintains information on which documents are locked for editing. The unique document identifier for each locked document is related to the process identifier of the editing process. This information is used during release of document locks. Anchor Relations. The anchor relation matches a unique anchor identifier with a document identifier and basic properties of the anchor including creator, creation time, modifier, modification time, and explainer. The primary index for this relation is the unique anchor identifier. Additional anchor information is stored in two other relations. The anchor view relation is used to store the location of the anchor markers in graphics documents where the marker is positioned independently from the anchor extent. This relation, which contains an anchor identifier, a view identifier, and three long integers, was designed to support applications that present more than one view of COMMUNICATION. OF T"_ ACM'January 19921Vo1.35, No.1 the document data. An example of this was InterSpect, a viewer for three-dimensional wire-frame models that was part of an early version of Intermedia. InterSpect supported both a two-dimensional and a three-dimensional view of the same data. The third relation with anchor information is the anchor application relation. Intermedia applications store various amounts of information to define an anchor extent in this relation, which contains an anchor identifier, three long integers, and a string. The string, which was included in the design to support extensibility, is unused. In the InterDraw application, for example, an anchor can consist of more than one graphic object. The identifier for each graphic object in an anchor extent is stored in one of these relations. Managing information about changing anchor locations in text streams presents a particular challenge. The InterWord application stores the information it needs to resolve the location of each anchor-consisting of beginning offset, ending offset, and an index into a document's history list-in a single instance of the anchor application relation. The history list, a sequence of numbers appended to the end of the document, tracks additions and deletions to the document. By indexing to the appropriate point in the history list, InterWord is able to resolve the appropriate location of each anchor. Link Relation. The link relation matches a unique link identifier with basic properties of the link including creator, creation time, modifier, and modification time. Each link relation consists of a pair of unique anchor identifiers and unique document identifiers for each side of the link. The primary index for this relation is the unique link identifier. Other Relations. The database also contains an object identifier relation which provides the next available 47 unique identifier for the major object types. The numbers generated by this relation are used to identify all new document, anchor, and link objects. Finally, the database contains database-computed queries stored in separate relations that contain the scope information displayed by the Web View. These relations contain total numbers of anchors, links, and documents for each unique web identifier. Link Engine Operations The initial operation of the Link Engine is the opening and dosing of a socket connection between the Link Client and the Link Server. The locations of the Intermedia document hierarchy. the Link Server, and the link database are passed as environment variables at run time. Once the connection is established, the Link Engine can open and dose the database, using the DBMS bound with the Link Server. Another basic operation returns the next availabJe unique identifier assigned to documents, links, and anchors. The Link Engine supports similar sets of operations on the data associated with documents, anchors, and links. These including adding, modifying, and deleting entire objects or data elements associated with each object. Move and delete operations are supported for folders (i.e., Unix directories) as wen. Separate methods for manipulating access rights, path name, and edit lock are supported for documents. As discussed previously in the subsection "Transfer of Webs," a set of operations for exporting and importing document, anchor, and link information is also provided. Exporting one or more folders creates a copy of the document hierarchy in those folders and a set of ASCII files in a canonical form containing the link data for webs in those folders. The importing of document and link data in this format is supported by a complementary set of operations. 48 Features for the Next Generation In designing and implementing Intermedia, we have identified a number of features that are critical for making hypermedia a useful part of the computing environment. The development of the Intermedia system ceased before we could implement solutions for these issues. Some of these features, such as wide-area hypermedia support, require a more extensive networking architecture than we have employed. Others, such as the need for filtering tools, are features that were in the original specification for Intermedia (see [25J for an early discussion of filtering), but were never implemented. The following discussion represents the results of our efforts to define future hypermedia system capabilities that took place at IRIS over the past several years. The next generation of hypermedia systems should explore solutions to these issues. Integration of Hypermedia into the Desktop If hypermedia functionality is isolated in specific hypermedia programs, the usefulness of that functionality will be very limited. Hypermedia functionality must be a feature of the entire computing environment, fully reflected in whatever graphical user interface integrates information on the user's screen. Whether that interface is built around a desktop, notebook. or room metaphor, hypermedia linking must be available in all documents, in all applications. This means the Link Engine. an equivalent of the Link Client/Link Server/DBMS layer in Intermedia. should be as integral to the computing environment as the file system is today. The functionality found in the Intermedia Layer, however, should be separated into two parts: highlevel integration support for applications and an intermediary process that handles link-related requests. Integration support can be provided through an application program interface (API) to a high-level toolkit, requiring the application developer to make calls to the API at the appropriate times. The toolkit should contain the embodiment of a system's hypermedia policies. In addition, a predefined set of callback routines will have to be implemented by each application. An alternate method of providing this integration support is an application framework such as Apple's MacApp. Between the application features found in this API and the database features found in the Link Engine, a general desktop hypermedia system will require an intermediary process we call a Link Hub. This Link Hub should serve four primary functions: • keeping the list of pending links (i.e., links not yet committed to the database); • managing the creation of links; • knowing how to follow a link (i.e., knowing how to locate documents and which application to invoke in order to open them); • providing link information to a link browser equivalent to the Intermedia Web View. By employing an API, a Link Hub, and a Link Engine, all applications should be able to incorporate linking. allowing hypermedia to be as common an integrating feature as cut, copy and paste is today. Multiple Webs The limitation of having only one web open at a time has proven too restrictive. We created the concept of a web in lntermedia to provide a specific context in which to collect aU related anchors and links. This context helped to separate sets of anchors and links overlaid on the same documents for different purposes. Restricting the user to one active web simplified the user interface. Developers should keep in mind that providing no context, that is displaying all links at all times, may seem adequate when hypertext January 1992/Vo1.35, No.1ICOMMUNICATfONa OF THE ACM

Disclaimer: Justia Dockets & Filings provides public litigation records from the federal appellate and district courts. These filings and docket sheets should not be considered findings of fact or liability, nor do they necessarily reflect the view of Justia.


Why Is My Information Online?