Case 1:13-cv-00919-LPS Document 307-2 Filed 03/10/21 Page 1 of 11 PageID #: 26718
`Case 1:13-cv-00919—LPS Document 307-2 Filed 03/10/21 Page 1 of 11 PageID #: 26718
`
`EXHIBIT 22
`
`EXHIBIT 22
`
`

`

`Case 1:13-cv-00919-LPS Document 307-2 Filed 03/10/21 Page 2 of 11 PageID #: 26719
`Case 1:13-cv-00919-LPS Document 307-2 Filed 03/10/21 Page 2 of 11 PageID #: 26719
`
`CyberDesk: A Framework for Providing Self-Integrating
`Ubiquitous Software Services
`
`Anind K. Dey, Gregory Abowd, Mike Pinkerton
`
`Andrew Wood
`
`Graphics, Visualization & Usability Center
`Georgia Institute of Technology
`Atlanta, GA 30332-0280 USA
`+1 -404-894-75 12
`
`{anind, abowd, mpinkert}@cc.gatech.edu
`ABSTRACT
`
`Current software suites suffer from problems due to poor
`integration of their individual tools. They require the de-
`signer to think of all possible integrating behaviours and
`leave little flexibility to the user.
`In this paper, we discuss
`CyberDesk, a component software framework that auto-
`matically integrates desktop and network services, requir-
`ing no integrating decisions to be made by the tool design-
`ers and giving total control to the user. We describe Cy-
`berDesk’s architecture in detail and show how CyberDesk
`components can be built. We give examples of extensions
`to CyberDesk such as chaining, combining, and using
`higher level context to obtain powerful integrating behav-
`lours.
`
`Keywords
`Adaptive interfaces, automated integration, dynamic inte-
`gration, software components, context-aware computing,
`future computing environments, ubiquitous services
`INTRODUCTION
`
`Users are tired of using monolithic application suites that
`allow little to no customization, just because they are in-
`dustry standards. Tightly integrated suites of tools/services
`currently available are unsatisfactory for three reasons.
`First, they require designers to predict how users will want
`to integrate various tools. Second, they force users to either
`be satisfied with design decisions or program their own
`additional complex relationships between the tools.
`Fi-
`nally, users must be satisfied with the available services
`themselves, because they are often given no opportunity to
`replace or add services.
`
`In response, software companies have been adopting the
`notion of component software: using small software mod-
`ules as building blocks for a larger application. While there
`are many competing standards (OLE [11], Active X [10],
`Java Beans [6], OpenDoc [1]), the prevailing view is to
`provide a framework which programmers and sophisticated
`users can build upon to create desired application suites.
`
`Unfortunately, current component solutions do not entirely
`relieve the burden from the designer and end user. Design-
`ers must still predict how users will want to integrate vari-
`ous services, without knowing what services the user will
`have. Designers must also build services specifically for a
`particular component solution, rather than build a general
`solution that can be used in multiple frameworks. Users
`
`School of Computer Science
`The University of Birmingham
`Edgbaston, Birmingham, B15 2TT UK
`amw@cs.bham.ac.uk
`
`now have the ability to replace and add services at will, but
`are still forced to accept the integration behaviour of serv-
`ices implemented by the designer.
`
`In this paper, we present the CyberDesk system, a compo-
`nent software framework that relieves most of the burden
`
`of integrating services from both the designer of individual
`services and the end user, provides greater flexibility to the
`user, and automatically suggests how independent services
`can be integrated in interesting ways. We begin by giving a
`short description of CyberDesk and presenting a sample
`scenario showing how the system could be used. Next, we
`discuss the architecture underlying the framework and de-
`scribe the benefits of our system. We end by showing how
`CyberDesk is being extended to provide more powerful
`integration behaviour and by describing our future plans.
`WHAT IS CYBERDESK?
`
`CyberDesk is a component-based framework written in
`Java, that supports automatic integration of desktop and
`network services [16]. The framework is flexible, and can
`be easily customized and extended. The components in
`CyberDesk treat all data uniformly, regardless of whether
`the data came from a locally running application or from a
`service running on the World Wide Web (WWW). The
`services and applications themselves can be running any-
`where, meeting CyberDesk’s goal of providing ubiquitous
`access to services.
`
`User Scenario
`
`The user selects which applications/components they would
`like to use by adding them to a Hypertext Markup Lan-
`guage (HTML) page. He loads the HTML page into a web
`browser running on his mobile computer and starts to inter-
`act with the system.1
`
`The user walks to a grocery store, and the system asks if he
`wants to see his shopping list, get more information about
`the grocery store, or get directions to his house. The user
`chooses the grocery list and goes shopping. He walks to a
`friend’s house but nobody is home. The system asks if he
`
`at
`available
`1 A demo version of CyberDesk is
`http://www.cc.gatech.edu/fce/cyberdesk. The video ac-
`companying the paper summarizes CyberDesk and shows
`more sample scenarios. Code samples are available at
`http://www. cc. gatech. edu/fce/cyb erdesk/samples.
`
`ARENDI-DEF800001151
`
`

`

`Case 1:13-cv-00919-LPS Document 307-2 Filed 03/10/21 Page 3 of 11 PageID #: 26720
`Case 1:13-cv-00919-LPS Document 307-2 Filed 03/10/21 Page 3 of 11 PageID #: 26720
`
`wants to check his friend’s calendar, contact him via e-mail
`or phone, or get directions to go home. The user chooses
`the first option and the system tells him that his friend is at
`work. So, he chooses the second option, sends his friend an
`e-mail saying that he stopped by, and starts walking home.
`On the way home, the system notifies him that he has re-
`ceived an e-mail from his friend. The user reads the e-mail
`
`(see Figure 1 below) which has information on a new book
`written by his favourite author. The e-mail contains a Web
`site address and an e-mail address for the author. The user
`
`highlights the e-mail address (a) and the system gives him
`some suggestions (b) on what he can do: search for more
`information on the author, put the author’s contact infor-
`mation in the contact manager, call the author,
`or send an
`e-mail to the author. He chooses the first two options (c
`and d), saves the e-mail, and heads home.
`
`U
`Cmraclkookflslngnumcs such
`l
`
`' Han
`3:21 Unirus'ed Java Annie: Windm/
`
`
`—Cl3l;;clnJLnn w: m s mum;——‘
` # Nebcape:Alravlslaseaull:SlmpleQuelyJohn Due . g
`
`
`m. an w...
`:- mun-m om: Dir-my mm.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` [gm Unrrusted Java Applet Wlndow
`
`
`
`
`
`.'
`
`
`<
` y
`may
`ancorbc mm; [Mariam
`2w Unrrusred Java Anpler Wlndow
`
`Figure 1. Mock screenshot of above user scenario
`
`The scenario described has not been completely realized
`with the CyberDesk system. Although, every action and
`suggested action in the scenario can be realized and sup-
`ported using the CyberDesk framework. We will show
`how CyberDesk can support these complex interactions
`without requiring effort by the user or the system designer.
`ARCHITECTURE
`
`The CyberDesk system has a simple but innovative archi-
`tecture.
`It is based on an event-driven model, where com-
`ponents act as event sources and/or event sinks. Events, in
`this current version, are generated from explicit user inter-
`action with the system. The system consists of five core
`components:
`the Locator,
`the IntelliButton,
`the ActOn
`Button Bar, the desktop and network services, and the type
`converters. The Locator maintains the registry of event
`sources and sinks. This allows the IntelliButton to auto-
`
`matically find matches between event sources and event
`sinks based on a given input event, a task normally required
`of the system or service designer. The IntelliButton dis-
`plays the matches in the form of suggestions to the user, via
`the ActOn Button Bar.
`It is through the ActOn Button Bar
`
`that the user accesses the integrating functionality of Cy-
`berDesk. The services are the event sources and sinks
`
`themselves, and are the tools the user ultimately wants to
`use. The type converters provide more powerful integrat-
`ing behaviour by converting given events into other events,
`allowing for a greater number of matches. The five com-
`ponents are discussed in greater detail below.
`
`User selects
`text
`
`
` data type
`
`"
`Deskto -——
`
`App.
`new data types
`converter
`
`
`
`
` provides
`service information
`for matching
`
`data type
`
`user picks
`service
`
`
`Figure 2: Runtime architecture diagram
`
`All five of the components have been implemented as Java
`applets for simplicity of network programming. We also
`chose Java for its promise of platform independence,
`its
`ability to execute within a web browser, and its object-
`oriented nature. The first two features support our goal of
`ubiquity, the second feature allows us to treat the browser
`as our desktop [3], and the last feature made development
`easier. Also, most of the network services implemented are
`available via the web, so the natural access method was via
`a web browser.
`
`Inter-component communication was performed using
`techniques based on the CAMEO toolkit [15], a C++ tool-
`kit built previously by one of the authors to facilitate the
`integration of application-sized components via the use of
`agent-like components. Components are able to invoke
`methods of other components directly via the use of a com-
`ponent handle. The parameter passed in these method calls
`is a structured message of the following form:
`:sender
`<1'd>
`:receiver
`<1'd>
`
`:interface
`:property
`:arguments
`
`<array ofjnterface names>
`<array of event/status names>
`<data>
`
`two fields contain the object handles for the
`The first
`method caller and method callee, respectively. The inter-
`face field refers to the types of actions the component sup-
`ports. Components declare their ability to be event sinks
`and sources via the interface field. This will be discussed
`
`further in the following section. The types of events that a
`component consumes or generates is stored in the property
`field. Data associated with events is passed in the argu-
`ments field.
`
`Locator
`
`The Locator component in CyberDesk keeps a directory of
`all the other components in the system, what events they
`can generate and/or what events they can consume.
`In any
`
`ARENDI-DEF800001152
`
`

`

`Case 1:13-cv-00919-LPS Document 307-2 Filed 03/10/21 Page 4 of 11 PageID #: 26721
`Case 1:13-cv-00919-LPS Document 307-2 Filed 03/10/21 Page 4 of 11 PageID #: 26721
`
`system where an arbitrary number of components (where
`types and location are unknown at compile time) are going
`to be interacting, a method of communication is required;
`in other words, a rendezvous mechanism that provides in-
`troductions between components is needed.
`
`Typically, such a directory service is run at a well-known
`location.
`In CyberDesk, the Locator is implemented as a
`uniquely named applet on an HTML page containing all the
`CyberDesk applets in use. Upon startup, each of the com-
`ponent applets register themselves with the Locator. It be-
`haves as a yellow pages directory by allowing any compo-
`nent to request a list of all the components supporting a
`particular interface and property. We currently support two
`different interfaces: method and select. If the interface field
`
`is set to “method”, the component contains a method(s) that
`will consume a particular event type.
`If the interface field
`is set to “select”, the component is declaring that it can
`generate a particular event type. Note that a component can
`support multiple interfaces, in any combination of selects
`and methods.
`
`The Locator supports the following API:
`insert (componentiname, interfaces [])
`adds a component's interfaces to the registry
`remove (componentiname, interfaces [])
`removes a component's interfaces from the registry
`locate (componentiname, interfaces [])
`locates and returns all components matching a given
`1nterface(s)
`IntelliButton
`
`The IntelliButton component is really the core of the Cy-
`berDesk system, as it provides the automatic integrating
`behaviour.
`It uses the Locator to keep track of all the
`desktop and network services and the type converters, and
`all the events sources and sinks they provide. When new
`components are added to the system, the IntelliButton noti-
`fies them that it is interested in all the events that they can
`generate (i.e. it is an event sink). So when a component
`generates an event,
`it notifies the IntelliButton and any
`other components that have expressed interest. The inter-
`ested components are called observers, as they observe
`events in other components. Any component can observe
`multiple components and can be observed by multiple
`components.
`
`The IntelliButton uses the event information (passed in the
`form of a structured message) to find any matches; i.e. any
`components registered with the Locator that can consume
`the event. It uses simple type checking to identify potential
`services that the user may wish to call upon to operate on
`the data associated with the event. The matches are dis-
`
`played to the user via the ActOn Button Bar, from which
`the user can select any or none of the integrating services
`suggested.
`If the user does choose one of the integrating
`services,
`the IntelliButton is notified and it accesses the
`correct service passing the associated data and event as
`parameters.
`In the above scenario, when the user high-
`lighted the e-mail address, the IntelliButton used that event
`
`information to determine what services were available
`
`(send an e-mail, save the contact information, etc.) and
`suggested them.
`ActOn Button Bar
`
`The ActOn Button Bar, as described before, is simply the
`user interface for the integrating IntelliButton. We chose to
`keep the interface separate from the actual
`integrating
`functionality to allow easier experimentation with alterna-
`tive interfaces. Currently, the interface is very simplistic.
`It is a dynamically generated list of buttons, where each
`button corresponds to a particular service that can be exe-
`cuted based on an user-generated event and its corre-
`sponding data. The list of buttons is provided by the Intel-
`liButton. Each button is labeled with a short textual de-
`
`scription of the following form:
`<action> <datatype> using <service>
`
`For example:
`
`Send e-mail to this EmailAddress using Netscape.
`
`Search for a string on the Web using AltaVista.
`
`The ActOn button bar also provides short help messages
`when the mouse is placed over the button. These messages
`are provided by the individual service and are made avail-
`able via the IntelliButton.
`
`Desktop and Network Services
`The previous three components discussed provide the core
`functionality of CyberDesk. Regardless of what tools the
`user wants to use,
`these three components are required.
`The fourth type of component, desktop and network serv-
`ices, are the actual services the user wants to access.
`Desktop services include e-mail browsers, contact manag-
`ers, and schedulers. Network services include web search
`engines, telephone directories, and map retrieval tools.
`
`To be included into the CyberDesk system, these services
`must register themselves with the Locator, providing a
`component handle and a list of interfaces that they support.
`These interfaces declare the list of services that they can be
`called upon to provide, and a set of data selection events
`that they can generate that could be used to trigger inte-
`grating behaviour. Currently, most data selection events
`are generated when the user selects some text with the
`mouse. Others are generated when significant changes in
`status occur, as will be seen in the section on higher level
`context.
`
`The declaration implementation is usually a simple matter
`of writing a wrapper object for an existing service. Cur-
`rently, the wrapper must be written by either the service
`designer, end user, or a middleman. We are looking at
`ways to automate this process. One method is to force all
`components in the system to support a common interface,
`like the JavaBeans initiative. This would enable the Cy-
`berDesk system to query each component and determine
`the events it can consume and generate.
`
`One of the services available in CyberDesk is a gateway to
`the AltaVista search engine available on the web. The
`
`ARENDI-DEF800001153
`
`

`

`Case 1:13-cv-00919-LPS Document 307-2 Filed 03/10/21 Page 5 of 11 PageID #: 26722
`Case 1:13-cv-00919-LPS Document 307-2
`Filed 03/10/21 Page 5 of 11 PageID #: 26722
`
`wrapper for this service, that allows it to interact with other
`CyberDesk components, consists of two main pieces. The
`first piece handles the declaration of its "method" interface
`to the Locator, stating that it can perform a web search on a
`String:
`properties : new CameoProperty
`CameoProper
`(“search or”, Class.forName(‘gava.lan XString”),
`‘ Search for a string on the We usrng
`tavrsta’ );
`Cameolnterface interfaces :
`_
`new CameolnterfaceC‘method”, propertres);
`
`The second piece actually implements the search when
`called upon by the IntelliButton. With this interface, this
`search would be suggested by the IntelliButton whenever a
`text string is the target of a selection (assuming the compo-
`nent in which the text selection is done, supports the "se-
`lect" interface). By their very nature, none of the network
`services support the "select" interface. They usually can
`not generate events and are of the form: receive input data
`and display output data. However, we will see how we can
`exploit this to provide even more interesting integrating
`behaviour in a process called "chaining".
`
`The desktop services are a little more complicated because
`they have the potential to support the "select" interface.
`This means the wrapper has to deal with generating the
`necessary data selection events.
`In this case, the wrapper
`has an interface declaration section, as before, where it de-
`clares any "method" and "select" interfaces. For example,
`the Scheduler’s interface is:
`CameoPro er
`ro erties : new CameoPro ert
`(“lodl<u1t:»yDIateR,
`p
`Class.forName(“cyberdesk.types.Date”),
`“Goto the date 1n the Scheduler”);
`_
`Cameolnterface interfaces[0 :
`new Cameolnterface(‘ method”, propertres);
`Cameolnterface interfaces[1 :
`new Cameolnterface(‘ select”, null);
`The first interface declares that it can consume date selec-
`tion events and the second interface declares that it can
`
`y
`
`generate data selection events.
`
`The second section, where it implements the interfaces is
`slightly more complicated than with the network services.
`The wrapper must have "hooks" into the original applica-
`tion code to intercept and broadcast the appropriate data
`selection events (for the "select" interfaces), and to execute
`a service on data passed to it (for the "method" interfaces).
`
`At the time of development, there were three ways to ap-
`proach this problem for the "select" interface. First, we
`could modify the original application's event processing
`loop to broadcast events in the CyberDesk fashion. Sec-
`ond, we could modify the original application code to make
`calls to a notification routine in the wrapper when data is
`selected. Third, we could rely on the original application to
`have a suitable API for retrieving those events. Obviously
`the third method is the simplest and is not intrusive to the
`original application. Unfortunately, not all of the applica-
`tions had APIs that allowed us to retrieve the necessary
`data selection events.
`
`All of the desktop applets currently being used in CyberD-
`
`esk (2 e-mail browsers, contact manager, 2 calendar man-
`agers/schedulers, scratchpad) were previously written by
`other Georgia Tech students. For those that did not provide
`sufficient APIs, we used the second method for capturing
`data selection events.
`It was far less intrusive than the first
`
`method, and we had access to the original code, allowing us
`to make changes.
`
`In the newest release of the Java Development Kit (version
`1.1), support was added for transferring data between (Java
`and non-Java) applications via a clipboard-style inter-
`face[7]. The use of this feature will allow us to avoid al-
`tering any application code in future versions of CyberD-
`esk.
`
`The problem is much simpler for the "method" interface.
`Either the application contained a method for acting on the
`given data, or it didn't. In cases where it didn't, we added
`additional methods to act on provided data. Note, that this
`didn't change the fundamental integration behaviour of Cy-
`berDesk, but only added additional features for us to ex-
`ploit.
`
`Type Converters
`Data typing is used extensively in the interface declarations
`of the event sources and sinks that applications provide.
`The property field that corresponds to each interface de-
`clares the datatype/event that a component is interested in
`or can provide. The CyberDesk system takes advantage of
`the Java type system to do the data typing.
`
`Initially, we hardcoded applications to generate events for
`different data types. For example, the e-mail browser de-
`clares that it can generate String selection events when text
`is highlighted, but also EmailAddress selection events
`when the "To:" or "From:" field in an e-mail message is
`selected. When EmailAddress selection events were gener-
`ated, they were passed through the CyberDesk system, as
`described before, to the ActOn Button Bar, which displayed
`services that could consume EmailAddress selection events
`
`(e.g. Send an E-mail to this E-mail Address using Net-
`scape). However, this required the applications themselves
`to be aware of the CyberDesk type system.
`It was also
`limiting since e-mail addresses could also appear in the
`unformatted body text of an e-mail message and only be
`recognized as a String selection.
`
`Consequently, we chose to use type converters. Using
`simple heuristics,
`it is possible to identify potential text
`strings that might be e-mail addresses.
`It would have been
`desirable to augment our e-mail browser with this capabil-
`ity, so that any time text was selected in it, it would try to
`convert the text to an EmailAddress object and create an
`EmailAddress selection event rather than just a String se-
`lection event. But, rather than just giving this type conver-
`sion capability to the e-mail browser, we wanted to add that
`ability to the system once, and allow it to be used in every
`application where e-mail addresses might appear. We took
`the type detection ability out of the individual applications
`and created type converters, an independent and extensible
`layer in the architecture.
`
`ARENDI-DEF800001154
`
`

`

`Case 1:13-cv-00919-LPS Document 307-2 Filed 03/10/21 Page 6 of 11 PageID #: 26723
`Case 1:13-cv-00919-LPS Document 307-2
`Filed 03/10/21 Page 6 of 11 PageID #: 26723
`
`CyberDesk type converters behave a lot like the Intelli-
`Button. When new components are added to the system,
`the converters determine which ones they are interested in,
`so they can add themselves to their list of observers. For
`example, the StringToEmailAddress converter is interested
`in all components that support the "select" interface for
`String objects and wants to observe them. So, when any
`component generates a String selection event, the String-
`ToEmailAddress converter (and any other observers) are
`notified, and the converter attempts to convert the given
`String object to an EmailAddress object (while other con-
`verters attempt to convert the object to another CyberDesk
`type).
`In the above scenario,
`this conversion was done
`when the user selected the e-mail address. The system ini-
`tially saw the selected data as a String but with this con-
`verter, it also saw it as an EmailAddress. This results in two
`related data selection events to arrive at the IntelliButton:
`
`one containing a string and one containing an EmailAd-
`dress. The IntelliButton will
`therefore seek integrating
`behaviour for both these types, allowing the user to access
`EmailAddress-relevant
`services where originally they
`wouldn’t have had the option.
`
`Currently the list of CyberDesk types include: Date, Pho-
`neNumber, MailingAddress, Name, URL, and EmailAd-
`dress. If any of the conversions can be made, then the con-
`verter generates a second, but related, selection event con-
`taining the newly typed data and sends it to observing enti-
`ties. This data also contains the original event. The system
`uses this information to ensure the type converters do not
`create an infinite loop (e.g. StringToEmailAddress, Emai-
`lAddressToString, StringToEmailAddress, etc.).
`WHAT DOES CYBERDESK GAIN US?
`
`CyberDesk provides a simple framework for adding new
`services and integrating them in reasonably intelligent
`ways.
`It relieves burdens from both the individual service
`designer and the end user. The individual service designer
`can develop a generic service, with a usable API, and not
`have to worry how it will be integrated into CyberDesk.
`The designer does not have to design specifically for the
`CyberDesk framework. The designer also doesn't have to
`think of all possible ways a user may want to integrate this
`service with another service, because the integrating be-
`haviour is inherent to the CyberDesk framework. CyberD-
`esk creates a dynamic mapping at runtime from user ac-
`tions to possible user actions, saving the designer from con-
`structing this map at design time.
`
`CyberDesk makes things easier for the user as well. The
`user has the ability to easily add and remove services from
`the framework and does not need to hunt for ways to inte-
`grate various tools. The user is often supplied with inte-
`grating suggestions that they do not expect or had not
`thought of, but are appealing nonetheless.
`EXTENSIONS
`
`The CyberDesk framework was designed to be easily exten-
`sible. Simple extensions to CyberDesk include adding addi-
`tional types, type converters, desktop services and network
`
`services. The real advantages with CyberDesk can be seen
`with more complex extensions that
`include adapting the
`behaviour of CyberDesk to individual use and creating more
`interesting integrating behaviour.
`
`Adding Types and Type Converters
`Type converters and types are often designed together, be-
`cause they are intrinsically connected. To make the task
`easy for a designer, we have implemented a Conver-
`sionApplet class which handles all the CyberDesk commu-
`nications and functionality. The designer is just required to
`implement three abstract methods:
`weCanConvert(selectedidata)
`determines if the input data is a type the converter
`can use
`
`potentialLoop(original data selection event and related
`se ection events)
`determines if this data was already converted to this
`type, checking for infinite loops
`tryToConvert(selectedidata)
`code that actually tries to convert the data to the
`output object of the type converter
`
`An example converter is the StringToEmailAddress con-
`verter, which is a subclass of the ConversionApplet class.
`The code for this component and all components described
`in
`the
`paper
`can
`be
`viewed
`at
`http://www. cc. gatech. edu/fce/cyb erdesk/samples.
`This
`converter looks at traditional ways of writing an e-mail
`address, and tries to map selected data to one of these ways.
`If it is successful, it returns an EmailAddress object. The
`ConversionApplet object
`is responsible for handling the
`ties to the CyberDesk framework.
`
`Adding Desktop Services
`As stated before, desktop services are a little more difficult
`to implement than other components. The main reason is
`that desktop services tend to have more complex function-
`ality than network services or type converters. Once a
`desktop application has been written, it is fairly straight-
`forward to implement a wrapper for use with CyberDesk.
`The wrapper must be a subclass of the original desktop
`application (slightly more difficult if the application is not
`written in Java, but is possible using the Java Native Inter-
`face [8]). The example below is the wrapper for the Con-
`tact Manager (see Figure 3), and it extends the ContactAp-
`plet class (the original application class).
`public class ContactManager extends ContactApplet
`implements CameoObject, Observer {
`
`The wrapper must declare its interfaces,
`Cameolnterface[] interfaces :
`new Cameolnterface[2];
`interfaces[0] : new Cameolnterface("select", null);
`CameoPro er
`ro erties :
`new Iéatnzeblgrogenfl 1 ];
`properties[ 0] :
`new CameoPro ert ("lookup”,
`Class.forName 'cy erdesk.type_s.Name
`"Lookup an entry for the name in the
`ContactManager" );
`
`_
`interfaces[g :
`new ameolnterfaceC'method", properties);
`
`ARENDI-DEF800001155
`
`

`

`Case 1:13-cv-00919-LPS Document 307-2 Filed 03/10/21 Page 7 of 11 PageID #: 26724
`Case 1:13-cv-00919-LPS Document 307-2
`Filed 03/10/21 Page 7 of 11 PageID #: 26724
`
`provide methods to execute any services it provides,
`/* method for invoking services supported by Contact
`Manager */
`public void manipulate(CameoMessage msg) {
`if (ms w. yetField
`(msg.P %)PERTY).equals("lookup")) {
`Strin * name : Name ms w. yetField
`g(msg.DA(T(A)).geiNafiié’O;
`/* call original ContactApplet method */
`showMe( name );
`
`}
`
`and provide a way to generate data selection events.
`
`The last requirement is a method that should be called when-
`ever data is selected in the application. Generating these
`calls would often require us to intrude on the application that
`we're wrapping, however we have defined a simple selection
`API that if implemented by the application, circumvents this
`somewhat. The selection API was based on the Observer
`
`performs service(s) on the input data
`
`The following is an example network service: WhoW-
`hereEmail.
`It is a gateway to the WhoWhere network
`service available on the web. When a name is input into
`the web service, a list of possible e-mail addresses corre-
`sponding to that name is returned. The CyberDesk network
`service takes a Name object, inputs it into the service and
`displays the results in a web browser. The complete class
`definition is in Appendix B, with pertinent selections be-
`low. The class declaration is a subclass of the ServiceAp-
`plet.
`public class WhoWhereEmail extends ServiceApplet {
`The service declares its interfaces as follows:
`
`properties[ 0] : new CameoProperty(
`"LookupEmarlAddressFor",
`Class.forName( "cyberdesk.types_.Name" ),
`"Looku person's e—marl address in the
`hoWhere listings");
`return new Cameolnterface( "method", properties );
`
`The actions the service can perform are defined in the ma-
`nipulate method:
`/* make sure the property is correct */
`
`if (ms xgetField msg.PROPERTY .
`equalséC ookup marlAddressFor‘ ){
`/* convert Name to usable form and
`construct URL */
`Strin * name : Name ms w. yetField
`é>msg.DA’l‘A ) ).ge)tNaér>née();
`URL search : new URL new String
`("http://queryl.whowhere.co wz/name.wsrch?"
`+ “name:“+name));
`/* load URL and display in browser */
`getAppletContext(). showDocument(
`search, "iwhowhere" );
`
`(
`
`}
`
`This is a simple service, interested in only one data selec-
`tion event - a Name. Other services are more complex and
`are interested in multiple selection events, but they are
`written and work in the same way. They declare additional
`properties, and implement the service for that property in
`the manipulate method.
`
`We have had several students develop simple extensions
`for CyberDesk,
`including desktop and network services,
`type converters and types. As a testament to the ease of
`development, at last count there were 6 desktop services,
`68 network services, 7 type converters, and 6 data types.
`
`Case Study: Accessing Mobile Data
`in our research
`A project currently under development
`group is LlamaShare, an architecture and set of applications
`for providing users and programmers easy access to infor-
`mation stored on mobile devices. There are two main goals
`for the LlamaShare project, one of them coinciding with a
`goal of CyberDesk. The first is to create an infrastructure
`that makes it simple for programmers to take advantage of
`mobile data in their applications. The second is to provide
`applications that demonstrate ubiquitous access to informa-
`tion.
`
`Currently, it is very difficult to get information off of a
`mobile device (a PDA like a Newton, for example) both for
`
`ARENDI-DEF800001156
`
`interface (note the class declaration above implemented the
`Observer interface) and Observable class provided in the
`Java language (version 1.0).
`It allows the designation of an
`object as Observable. Any object can choose to observe
`changes in an Observable object. For CyberDesk's purposes,
`an application must designate the data selected by a user to
`be observable and when the selected data changes, it must
`notify all observers.
`
`a:
`.1 Mail:fumm cammmvgrn
`
`Future Compuling Environments
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` that
`
`
`
`
` Manama? PPnplP (Jim/yKenn/(Is
`E Rh
`5qu
`VIOW Ga Bcoxnumx
`(Mons
`ulmcxow