KR20100105544A - Gesture-based collaboration - Google Patents

Abstract

Generally described, the present invention relates to a network operating system that provides more efficient ways of elevating the connectivity of computer networks. In one embodiment, an XML virtual machine is implemented that accepts as input the high level application code written in the XML programming language. Functionality is provided for interpreting or translating application code written in XML programming language into code suitable for execution across computer platforms. The XML virtual machine also supports a model view controller design paradigm that enables true data abstraction from applications to common data models. Multi-instance applications can be created and executed, with each instance potentially supporting multi-views.

Description

Gesture-Based Collaboration {GESTURE-BASED COLLABORATION}

Computer networks that exchange data in accordance with common protocols such as the Internet Protocol (IP) are increasingly used to perform various tasks between remote systems and users. The connectivity available from computer networks has led organizations and others to find solutions that enable them to participate in collaborative processes. In this regard, many existing Web sites, network portals and distributed applications allow users to share and collaborate on data in a variety of ways. To further support collaboration, resources are increasingly being made available as services on the network. Generally speaking, service refers to software and hardware that allows access from a network independent of the underlying technologies. Thus, a network service is often described as "loosely coupled" to the operating system, programming languages, and hardware components on which the service is implemented. As a result, even if different basic techniques are used, network services can be combined to create distributed applications.

The term "cloud" computing is often used to describe the tendency to increase the number of services made available from the network. As network bandwidth and connectivity increase, the applications and economic benefits of cloud computing will continue to increase. However, existing systems use a machine-centric operating system to manage communications over the network and use collaboration. In this regard, the core design of the machine-centric operating system was established before the development of computer networks such as the Internet. As a result, existing systems cannot provide a generalized collaboration environment in which network communications are readily integrated into applications and other aspects of the user experience. Instead, applications in development that make use of sharing and engagement in a collaborative process are still very hard for all users and / or organizations and ultimately too difficult or expensive. Therefore, there is a need for a network operating system that provides more efficient ways of affecting the connectivity of computer networks.

Generally described, the present invention relates to a network operating system that provides a more efficient way of affecting the connectivity of computer networks. In one embodiment, an XML virtual machine is implemented that accepts as input high level application code written in the XML programming language. Functionality is provided for interpreting or translating application code written in the XML programming language into code suitable for execution on computer platforms. In addition, the XML virtual machine supports the Model View Controller (MVC) design paradigm that enables true data abstraction from applications to the collaborative data model. Multiple instance applications in which each instance supports multiple views can be created and executed.

The advantages associated with the above-mentioned aspects of the present invention will be readily understood with reference to the following detailed description in conjunction with the accompanying drawings.
1 is an illustrative pictorial illustration of a networking environment including a server-side data center and a plurality of client computers suitable for describing aspects of the present invention.
2 is an exemplary pictorial illustration of a networking environment including a server-side data center and a plurality of client computers suitable for describing aspects of the present invention.
3 is a block diagram illustrating an exemplary hardware architecture of a computing device suitable for describing aspects of the present invention.
4A-C are block diagrams of example platform environments in which the present invention may be implemented.
5A-B are exemplary pictorial illustrations of a networking environment including a server-side data center and a plurality of client computers suitable for describing aspects of the present invention.
6A-B illustrate exemplary process and UI XML documents associated with an application suitable for describing aspects of the present invention.
7A-C illustrate an example graphical display that visually illustrates graphical elements of the application described semantically in FIGS. 6A-B.
8A-B are pictorial illustrations of components suitable to illustrate aspects of the present invention.
9 is a block diagram with exemplary managers set up to implement aspects of the present invention.
10A-C are diagrams illustrating an example application startup routine that handles processing for opening an application package according to one embodiment of the invention.
11 is an exemplary flow diagram illustrating a routine for opening and initializing logic defined in an application's process code.
12A-B show an example flow diagram illustrating an execution method that is set up to execute tasks in a process step.
13 is a diagram of an open handling routine for opening an XML document in accordance with one embodiment of the present invention.
14A-14B are diagrams illustrating interactions between objects suitable for describing aspects of the present invention.
15A-B are exemplary flow diagrams illustrating operation handling routines for implementing functionality in accordance with one embodiment of the present invention.
16 is a diagram of a bind handling routine that binds an object to a data model according to one embodiment of the invention.
17A-B are diagrams illustrating a trigger activation routine for causing application code to be executed in response to an activated trigger in accordance with one embodiment of the present invention.
18 is a diagram of a decision handling routine set up to perform an valuation that directs the flow of application execution based on valuation.
19 is a diagram of a change handling routine illustrating logic for implementing change operations in accordance with one embodiment of the present invention.
20A-C are diagrams illustrating a data update routine that implements logic to modify the content of a data model in accordance with one embodiment of the present invention.
21 is a diagram of a setup rules routine showing logic for setting components rules in a data model according to an embodiment of the present invention.
22 is a diagram of a notify listener routine for notifying objects of a data update according to one embodiment of the invention.
23 is a diagram of a rendering routine for rendering an applications view in accordance with one embodiment of the present invention.
24 illustrates a block diagram suitable for describing methods for applications interacting with various exemplary data sources in accordance with an embodiment of the present invention.
Figure 25 illustrates a block diagram suitable for describing the XML file system provided by the present invention.
FIG. 26 illustrates a message server configured to synchronize data across a network according to an embodiment of the present invention.
27 illustrates additional aspects of a message server according to other embodiments of the present invention.
28A-28D illustrate an example method of retrieving a file from a file system provided by the present invention.
28E illustrates an excerpt of an exemplary file suitable for describing aspects of the present invention.
29 illustrates a method configured to retrieve a list of files according to an embodiment of the present invention.
30A-30C illustrate a method for creating a file in an XML file system according to another embodiment of the present invention.
31A-31E illustrate a method of opening a file existing in an XML file system according to another embodiment of the present invention.
32A-B illustrate a method of initiating startup of a network operating system on a client computer in accordance with one embodiment of the present invention.
33 illustrates a method of mounting a group of network operating systems according to another embodiment of the present invention.
34 illustrates a method for transitioning a client computer from an online state to an offline state according to an embodiment of the present invention.
34B illustrates an exemplary pictorial illustration of a plurality of drives that may be used for network collaboration in accordance with another embodiment of the present invention.
35 illustrates a method for transitioning a client computer back to an online state when the client computer operates in an offline state according to another embodiment of the present invention.
36 illustrates a method for processing a request to create a new file in a manner that enables enhanced network communications in accordance with another embodiment of the present invention.
37 illustrates a shared data file used with a chat application suitable for describing additional aspects of the present invention.
38 illustrates a relationship between components and a data model used by a chat application according to another embodiment of the present invention.
39 illustrates updating of a shared data file used to enable a chat conversation in accordance with another embodiment of the present invention.
40 illustrates an exemplary set of communications performed in a chat conversation according to another embodiment of the present invention.
41 illustrates the use of shared data when performing cooperative communication between a plurality of clients.
42 illustrates a user interface of an exemplary application suitable for describing further aspects of the present invention.
43 illustrates a user interface of an example application suitable for describing further aspects of the present invention.
An illustrative pictorial illustration of a networking environment including client computers.
45 is a diagram of a collaboration start routine that causes a collaboration session to be started in accordance with one embodiment of the present invention.
46 is a diagram of a state synchronization routine to cause applications running on different clients to synchronize in accordance with one embodiment of the present invention.
47 illustrates a user interface of an example application suitable for describing further aspects of the present invention.

Generally described, aspects of the present invention relate to network operating systems that enable the development of cloud computing at the Internet level. In a practical embodiment, the network operating system described herein uses XML (eXtensible Markup Language) as a general-purpose language for representing data. Thus, the examples provided below may illustrate the functionality of a network operating system related to XML structured data and documents. In this regard, many advantages and synergies are achieved by using XML associated with it. However, it will be apparent to those skilled in the art that the present invention may be implemented using other basic techniques, or combinations of techniques, not described herein without departing from the scope of the claimed technical features. In addition, the examples and descriptions for the descriptions provided below are not intended to limit the present invention to the precise forms disclosed. Similarly, the steps described below can be interchanged with or combined with other steps to achieve the same result.

1, the following is intended to provide an overview of a networking environment 100 that may be used to implement aspects of the present invention. As shown in FIG. 1, networking environment 100 includes a server-side data center 102 associated with servers 104. Networking environment 100 also includes a plurality of client computing devices associated with user 112, including mobile phone 106, desktop computer 108, and thin client 110. In this regard, server-side data center 102 communicates with mobile phone 106, desktop computer 108, and thin client 110 via network 114, the network comprising a local area network (LAN), a wireless network, It may be implemented as a wide area network (WAN) such as the Internet. As is known to those skilled in the art, the computing devices described in FIG. 1 may exchange files, instructions, and other forms of data over the network 114. However, network communication protocols such as TCP / IP will be apparent to those skilled in the art, and therefore the protocols will not be described herein.

In existing systems, application programs available on one type of computing device may not be compatible with other types of devices. This incompatibility creates various problems. For example, in a general purpose computer, a user would write a specific application that accesses email messages. On the other hand, in order to access an e-mail from a resource limited device such as a mobile phone, another program with different features and interfaces may be required. This incompatibility is not good for providing a common user experience, or for reducing the amount of knowledge and skills required by the user. Moreover, even though many applications implement similar or identical functionality, excessive development time is spent on developing applications for different kinds of devices.

Aspects of the invention may be applied to a plurality of other contexts, the following of which is merely exemplary. In one embodiment, the user's applications and data are accessible from any computing device available to the network operating system. As illustrated in FIG. 1, user 112 may connect to network 114 from mobile phone 106, desktop computer 108, and thin client 110. In response, server-side data center 102 delivers network operating system services to the appropriate device. More specifically, client-side components of the network operating system and user applications can be delivered and built up every time the user connects to the network. The applications run locally on the appropriate client computing device and do not run on servers. User data is cached on the client computing device but will persist in storage maintained by the server-side data center 102. Thus, communications between client computing device 106-110 and server-side data center 102 are primarily performed to obtain documents and update data. When the client goes offline, the client side component of the network operating system causes the data update to be temporarily stored locally. These updates are sent to the server side data center 102 and are synchronized with all changes when the network is reset.

In one embodiment, the network operating system may provide a common experience across computing devices of each user. In this regard, a common desktop application is delivered and built on heterogeneous kinds of computing devices. From the common desktop, all application programs and data of the user can be connected. For example, one email program that can be used in the network operating system can be connected by all of the client computing devices 106-110 by the user 112. Since user data is available at the server-side data center 102 and delivered as a service, the same applications (eg email program) and data (eg email messages) are available no matter what computing device is used. Do.

The services provided by the network operating system to the client computing device may be customized according to user preferences and other variables. In this regard, configuration data is defined that defines how network operating system services are to be provided. For example, a user may set preferences with different sets of available application programs or data, depending on the computing device in use. As another example, a user may connect to the network 114 from many access points, including an unsecured wireless connection. In this example, security attributes can be set such that certain services and / or data cannot be accessed because of the unsecured nature of the network connection. As will be appreciated by those skilled in the art, the above examples represent some of the ways in which network operating system services can be modified using the present invention.

For convenience, FIG. 1 illustrates a server-side data center 102, server computers (which may be used in a network environment 100 in which complementary tasks may be executed by remote computing devices connected via a network 114). 104, mobile phone 106, desktop computer 108, and thin client 110. However, the present invention provides other types of client computing devices, such as, but not limited to, laptop computers, tablet computers, personal digital assistants, hybrid / embedded devices, set top boxes, media centers, and the like. Can also be performed. Moreover, those skilled in the art can understand that the present invention can be implemented in other network configurations and that the example shown in FIG. 1 should be construed as illustrative only.

2, another networking environment 200 that can be used to describe additional aspects of the present invention is described. As shown in FIG. 2, server-side data center 202 may be coupled to a private network, such as enterprise network 204. In this example, additional network operating system services are provided directly to clients 206, 208, 210 via enterprise network 204. However, the network operating system is still provided and managed from the server side data center 216, and the enterprise server side data center 202 only provides additional services. In addition, the same additional services may be provided to clients outside the corporate network 204. In this example, server-side data center 202 provides network services over the Internet 214. Similar to the description above, the clients 206-212 can be any computing device (mobile phone, desktop computer, thin client, etc.) that can be used in a network operating system. In another embodiment, the networked operating system may be provided directly by the enterprise server side data center 202 with additional services and may be connected to an external server side data center 216 outside the corporate network 204. May or may not (by security settings).

The network operating system enables participation in collaborative processes. One aspect of the present invention is an XML file system serving as a network repository capable of storing all kinds of data such as XML documents, executable files, binary files, multimedia, and the like. The XML file system can be implemented in a server side data center 202 or 216 that manages physical storage and data connections. In addition to common file system functions, the XML file system allows for various kinds of collaboration spaces that can be defined. In an example embodiment, the types of collaboration spaces supported include communities, groups, friends as well as subsets (eg, subcommunities, subgroups, etc.) within existing collaboration spaces. The root folder within the XML file system acts as a repository for each community, group, or other collaboration space created. In addition, folders and files can be created within an XML file system associated with individual users. In another embodiment, collaboration between different users may be dynamically enabled without users sharing the collaboration space within the XML file system. As described in detail below, messaging services are provided that allow for creating a collaboration session or approving requests in real time. Thus, even if an existing collaboration space is not defined, users can establish new relationships through dynamically created collaboration sessions.

Once the client-side component of the network operating system begins to run, a login prompt can be used to obtain user credentials. To enable transparent access, each folder associated with a user can be mapped from the XML file system as a virtual drive on the client. For example, if a user is a member of a particular group, the group folder appears as the impersonation drive on the client. In one embodiment, a folder in an XML file system includes XML structured data that defines shared resources of a collaboration space. These shared resources include, but are not limited to, applications, data documents, access and security settings, user lists, statistics, schedules, and the like. The XML file system may, in one embodiment, work with a repository and database replacement for one or more applications running in a networked operating system environment. As described in detail below, data maintained in a collaborative and distributed database can be automatically synchronized through the transaction management provided by the present invention. By building applications that use this kind of collaborative and distributed database, applications inherit the features of the database and can easily share data.

Since the XML file system is followed by an application programming interface (API), other embodiments of the server-side data center 202 are possible. In this regard, other XML Web services that can be provided from an XML file system provide a new application that runs in an operating system environment where abstractions are networked on legacy applications and databases within an enterprise, or through multiple applications. It is preferable when it is required to be able to. Customized implementations of the XML file system can choose the level of functionality to support. For example, support for synchronizing transactions may be omitted at one level of support.

In addition to managing data connections, the XML file system provides an integrated framework for creating and customizing associations between users in a way that synchronizes data and coordinates transactional control of data updates to enable collaboration. For example, an application may be shared with a group of users (eg, friends) along with associated user data. The functionality of all user data associated with a shared application can be represented by XML documents maintained by a group or user folder, along with other resources. The XML file system provides a way for each user to access user data associated with a shared application. In this way, a shared application can be delivered and built on a plurality of clients by each group member manipulation data that manipulates data of the same group or user folder.

As noted above, clients outside the corporate network 204 (eg, client 212) can obtain services from server-side data center 202. By way of example, an employee or other user may be provided access to corporate resources when outside of the corporate network 204. Thus, client 212 may be a home computer, mobile phone, or the like, connecting to server-side data center 202 via the Internet 214. In this regard, one of ordinary skill in the art may recognize that the networking environment 200 may include additional networks other than those described in FIG. 2, and the example configuration of FIG. Understand that it can be reconstructed. For example, a network access point for client 212 may start from a local area network, a wireless network, a wide area network, or the like, which may also apply to server side data centers 202 and 216.

In another embodiment, clients may obtain other kinds of services from enterprise server-side data center 202 in accordance with one or more variables. Instead of providing the same network services to each client, the network services can be set according to the location of the client's network access point. For example, clients 206-210 that connect directly to enterprise network 204 may be provided with additional customized services specific to the enterprise. Outside the corporate network 204, external services can be delivered from the server-side data center 202 to the client 212 (eg, a customer, supplier, employee, or user associated with the enterprise). To enable secure delivery of modified network services, resources may be allocated by the server side data center 202 managing other kinds of clients. In the embodiment shown in FIG. 2, server-side data center 202 includes a hard drive 220 assigned to provide modified services to clients 206-210 within the network. On the other hand, hard drive 222 may be assigned to provide more generalized services to clients outside the corporate network, for example, client 212. In yet other embodiments, services provided to a client may depend on other variables such as user information, configuration information, client type, and the like.

In one aspect, network operating systems provide a more generalized framework for enabling real-time "business-to-business" collaboration. Collaboration spaces can be created that allow different companies to access resources in a common data store. In the example shown in FIG. 2, client 212 may be associated with a cooperating company for an enterprise that maintains server-side data center 202. In this regard, the clients described in FIG. 2 may be operated by software agents interacting with users or server-side data center 202. When run by software agents, aspects of the present invention efficiently create an Electronic Data Interchange (EDI) relationship that shares users associated with an enterprise or resources using an XML file system individually. EDI services may also be provided by a publicly available server-side data center 216, depending on security requirements. The group folder may be created in an XML file system that stores the shared resources of the partnership and / or defines the business rules of the EDI. Similar to the description above, group folders can be mapped to virtual drives at the client 212, providing transparent access to shared resources outside the corporate network 204. Importantly, the shared application can be delivered as XML structured data from the server side data center 202 to the clients 206-212. Each client 206-212 builds and runs the application locally and reports data updates to a shared folder in the XML file system or to individual folders of each user. In one embodiment, server-side data center 202 manages data update coordination such that multiple clients can access and update the same documents at the same time. This coordination may also be performed by the server side data center 216 if the data is stored in its own XML file system.

In one aspect, the network operating system allows clients 206-212 to have transparent access to external network services. Using an application program interface (API), a communicator can be created that abstracts data handling functions that interface with all (internal or external) network services. By way of example, developers can communicate with, among other things, network servers hosting XML Web services, REST services, XML resources, RSS or Atom feeds, text, csv text, Hypertext Markup Language (HTML) based websites. Can create them. 2, an instance of a communicator or “channel” can be instantiated by the client 212 to interact with the web service 218. In this example, network operating system services are accessible to the client 212 using the server-side data center 216 as a proxy in the public network (eg, the Internet 214). Further, even if network operating services are provided from a private network (eg, corporate network 204), web service 218 is accessible to clients 206-210 using a communicator. In this example, server side data center 216 acts as a proxy to manage communications between clients 206-210 and web service 218. Thus, when connecting to network services, clients can use a communicator to abstract data handling functions. This aspect of the invention simplifies application development because it does not require developers to repeatedly write code that manages communications between a client and a network service.

Although FIG. 2 illustrates an enterprise network 204, those skilled in the art can understand that this is a simple example. Instead, the present invention may enable data synchronization and collaboration in other kinds of network environments. Thus, the description provided with reference to FIG. 2 is equally applicable to local area networks maintained by homes or small businesses as well as wide error-ear networks such as the Internet. Moreover, the examples described above have been made with reference to a server side data center 202 that provides separate network services to each client 206-212. However, server-side data center 202 may be configured to provide network services that complement resources or services of other devices or networks. For example, a small business can maintain a network drive for all clients connected to the local area network. Server-side data center 202 may provide data storage services that complement the public network drive of server-side data center 216 by providing additional storage or allowing backup in the event of a public network device failure. In another embodiment, a home network may use a media center computer to provide each local client connection to digital media. To complement the storage of the media center computer, the server side data center 202 may provide a virtual drive to all devices connected to the home network. In this regard, based on user preferences or other configuration variables, the virtual drive may allocate actual storage of data between the media center computer and the server side data center 202.

Referring to FIG. 3, an exemplary hardware structure of the computing device 300 is described. Although FIG. 3 is described with reference to a computing device implemented as a client on a network, the following description is also applicable to servers or other devices that may be used to implement the present invention. Moreover, one of ordinary skill in the art will appreciate that the computing device 300 may be any of the devices currently available or later developed. In the most basic configuration, computing device 300 includes system memory 304 coupled by at least one central processing unit (CPU) 302 and communication bus 306. Depending on the exact configuration and type of device, system memory 304 may be volatile, such as read only memory (ROM), random access memory (RAM), EEPROM, flash memory, or similar memory technology. Or a nonvolatile memory. Those skilled in the art can appreciate that system memory 304 generally stores data and / or program modules that are readily accessible and / or currently operating in CPU 302. In this regard, the CPU 302 serves as a computing center of the computing device 300 by supporting the execution of instructions.

As further described in FIG. 3, computing device 300 includes a network interface 310 that includes one or more components that communicate with other devices over a network. As described in detail below, the present invention can access basic services using a network interface 310 that performs communications using a generic network protocol. In the example embodiment shown in FIG. 3, the computing device 300 further includes a storage medium 308. However, as will be described in more detail with reference to FIG. 4A, network operating system services may be accessible using a computing device that does not include means for maintaining data on a local storage medium. Thus, the storage medium 308 shown in FIG. 3 is indicated by dashed lines to indicate that it is optional. In any case, storage medium 308 is volatile or nonvolatile, removable or fixed, a technology capable of storing information, such as hard drives, solid state drives, CD-ROMs, DVDs or other disk storage, magnetic cassettes. It may be implemented using magnetic tape, magnetic disk storage, and the like, but is not limited thereto.

As used herein, “computer readable medium” includes volatile and nonvolatile and removable and fixed media implemented in a method or technology capable of storing information such as computer readable instructions, data structures, program modules or other data. do. In this regard, the system memory 304 and storage medium 308 shown in FIG. 3 are merely examples of computer readable media.

Suitable implementations of computing devices including the CPU 302, the system memory 304, the communication bus 306, the storage medium 308, and the network interface 310 are known and available for purchase. 3 is omitted for the sake of clarity and for clarity of understanding what is described in the claims, as typical components of many computing devices. In this regard, computing device 300 may generally include input devices such as a keyboard, mouse, microphone, touch input device, and the like. Similarly, computing device 300 may also include output devices such as displays, speakers, printers, and the like. All these devices are well known and will not be described here.

4A-4C, exemplary platform environments in which the present invention may be implemented are described. In this regard, FIGS. 4A-4C illustrate hierarchical relationships between platform layers of computing device 300 (FIG. 3). More specifically, the platform layers of the computing device 300 described in FIGS. 4A-4C are the hardware platform 403 at the bottom tier, the machine operating system 404 at the middle tier, and the application platform 406 at the top tier. ). Of course, those skilled in the art can understand that the platform layers of the computing device 300 shown in FIGS. 4A-4C are merely exemplary.

Since the exemplary hardware platform 402 of the computing device 300 has been described above with reference to FIG. 3, no further description of these components is provided. However, as described in FIGS. 4A-4C, computing device 300 may include a machine operating system 404. In this regard, the machine operating system 404 may be from any of a family of general-purpose operating systems such as Microsoft® operating system, Apple® operating system, UNIX® operating system, Linux® operating system, Nokia® Symbian, Google® Android, and the like. have. The machine operating system 404 may be an operating system tailored to specialized computing devices that use non-generic hardware such as thin clients, mobile phones, mainframes, supercomputers, and the like. In addition, machine operating system 404 may be an operating system designed to meet certain configuration parameters, such as real-time operating systems, embedded operating systems, and the like.

The purpose of machine operating systems is to abstract the details of access and other hardware resource usage. Thus, machine operating systems perform almost all basic system tasks, such as managing I / O (inputs and outputs) with hardware components, memory management, task scheduling, and the like. In this regard, machine operating systems typically provide services to application programs via APIs. The provision of services through the API alleviates the effort of application developers to manage the implementation details of the connection or to use underlying computer platforms. Correspondingly, aspects of the present invention use the machine operating system 404 only for basic services available from all modern computer platforms. In this regard, services may be used to establish network connections that interface with networking hardware and communicate using the TCP / IP protocol.

In the embodiment shown in FIG. 4A, computing device 300 includes a web browser 408 that operates at the top layer of application platform 406. As discussed above, client-side component 410 of the network operating system may be delivered to and built on computing device 300. In the embodiment shown in FIG. 4A, client-side component 410 operates within the context of web browser 408. In this regard, the web browser 408 can be any number of browser applications that communicate with remote devices using TCP / IP network communication protocols, including but not limited to Mozilla Firefox®, Microsoft's Internet Explorer®. Can be entered.

In the embodiment shown in FIG. 4A, the client-side component 410 does not interact directly with the machine operating system 404. Instead, the basic services used by client side component 410 are connected from web browser 408. Those skilled in the art will appreciate that HTTP is, above all, a protocol above TCP / IP that allows network resources to be requested or received using uniform resource locators (URLs). Typically, web browsers obtain web pages formatted with markup languages such as Hypertext Markup Language (HTML), Extensible Markup Language (XML), or formatted with Java Script Object Notation (JSON) and / or JavaScript. Generate HTTP requests to do this. In one embodiment, the web browser 408 is configured by the client-side component 410 of the network operating system to perform network communications using HTTP and to render graphical elements represented in HTML among the graphical presentation techniques available in the web browser. Is used.

In the embodiment shown in FIG. 4B, the client-side component 410 of the network operating system connects directly to the services of the machine operating system 404 without using a web browser. Aspects of the invention allow applications to be delivered and built to all computing devices. Such web browsers are typically set to display graphical elements according to a predetermined phase size and / or layout. Thus, a general purpose web browser may not be suitable for rendering graphical elements on all kinds of computing devices on which the present invention will be implemented. For example, using a browser to render graphical elements in a small form factor computing device can be problematic. In this regard, the predetermined page size and / or layout expected by the web browser may not be too large or suitable for a given available form factor. As described in FIG. 4B, the client-side component 410 of the network operating system may be implemented as a stand-alone application or as a machine operating system. In this case, client-side component 410 is configured to perform graphics rendering in a manner appropriate to a given form factor of the computing device without using a web browser. Moreover, in this embodiment, basic services for performing network communications may be obtained directly from the machine operating system 404 or built into the client side component 410.

In the embodiment shown in FIG. 4C, the computing device 300 does not include a traditional machine operating system. Instead, basic services for interfacing with the hardware platform 402 are built into the client side component 410. In this embodiment, the client side component 410 implements basic system tasks for memory management, task scheduling, and the like. By building this kind of basic machine services in the client-side component 410, aspects of the present invention can be easily customized and deployed for use with specific hardware platforms. In other words, the client-side component 410 may be configured to be independent of the services provided by the provider of the machine operating system.

As discussed above, client component 410 may be delivered to a network service and built each time a user connects to the network. As described in FIGS. 4A-4C, client-side component 410 is suitable to be implemented as a standalone application, as a machine operating system, or within the context of a web browser. In all these embodiments, server-side data center 202 or 216 may provide application logic to client-side component 410 as a network service. Thus, computing devices of limited resources that do not have a storage medium (eg, hard drive, CD-ROM, DVD, etc.) can be used to connect to the network operating system provided by the present invention. In this regard, client-side component 410 and other network operating system data may be temporarily stored in system memory (ROM, RAM, etc.) rather than continuing to a local storage medium. Thus, applications that may be used in the network operating system do not need to be "installed" on the computing device 300 as the application may be delivered as a service.

5A-5B, a description is provided of how a common data model can be used to deliver network operating system services in accordance with the present invention. The network operating system supports the model view controller (MVC) design paradigm by separating application components into different layers, that is, model views and controllers. In a practical embodiment, XML documents are "models" or collaborative data in which information is represented in a network operating system environment. The use of a common data model (eg, an XML document) in this context benefits a lot and will be clearer in the description below.

The networking environment 500 shown in FIGS. 5A-5B includes a server side data center 502 communicatively coupled to respective clients 504, 506 via a network 508. As described above, client-side components of the network operating system may be dynamically delivered from the server-side data center 502 to the respective clients 504, 506, or may be installed locally at both clients 504, 506. have. In both cases, the client-side component of the network operating system provides an XML virtual machine 510 to interpret XML structured applications or to run on clients 504 and 506. When delivered as a service, aspects of the present invention allow the network operating system to "boot" by delivering a process XML document from the server-side data center 502. In this regard, the process XML document provides logic describing a startup sequence for clients 504 and 506. As described in detail below, this process XML document is executed within the XML virtual machine 510. The startup sequence typically instantiates and manipulates a set of objects in the XML virtual machine 510 so that other applications can run.

As mentioned above, XML may serve as a "model" or co-format in which application logic and other data are represented in a network operating system environment, but other models, data formats, and structures of data also implement the present invention. It can be used to In one embodiment, programming languages are provided that allow XML applications to be designed at a very high level of abstraction. Those skilled in the art will appreciate that XML is a highly structured, transferable, and transformable language. Thus, the representation of application logic at high levels of abstraction, such as XML structured data, results in memory efficient and compact applications. In particular, a platform is provided for executing the logic of an application represented in one or more well-formed XML documents. Application functionality is separated in accordance with the MVC design paradigm, eliminating repetitive tasks performed by traditional systems. Thus, when compared to existing systems, the transmission of application code from server-side data center 502 to clients 504 and 506 consumes a small amount of bandwidth. Moreover, since the application logic is executed using the XML virtual machine 510, the execution of the application logic using the present invention eliminates or significantly reduces the bandwidth consumed. Interactions that were handled by performing a server "round trip" are handled directly at clients 504 and 506 without requesting or relying on network communications with server-side data center 502.

One aspect of the invention is an XML virtual machine 510 that provides an application programming interface (API) for executing and developing applications on clients 504 and 506. In this regard, the high level application code written in the XML programming language is taken as input and executed locally on the clients 504, 506 by the XML virtual machine 510. The functionality is provided for interpreting or translating high level application code into interpretable code, byte code or other low level languages suitable for execution on any platform. In this regard, the XML virtual machine 510 abstracts underlying computer platform and network resources such that applications run in the same way on all kinds of computing devices. Thus, the XML virtual machine 510 is completely platform and hardware independent, such as, for example, Microsoft .NET®, Java, C, C ++, HTML, JavaScript, AJAX, Adobe® Flash, Microsoft® SilverLight, and the like. It can be implemented using any programming technique currently available or under development, including but not limited to.

With reference to FIG. 5B, additional aspects are described regarding how the joint data model is used to provide network operating system services. The networking environment 500 described in FIG. 5B includes the same components described above with reference to FIG. 5A. On the other hand, an XML file system 512 that provides storage and other network services is shown in server-side data center 502. Thus, while network operating system services are provided, data maintained in the XML file system 512 may be accessed by clients 504 and 506. In one aspect, the present invention implements a client-side cache 514 for managing the storage of documents and other run-time data of clients 504, 506. As described in FIG. 5B, data stored in the client-side cache 514 is easily accessible to the XML virtual machine 510. In one embodiment, the client side cache 514 allows the XML virtual machine 510 to continue running applications even if the network connection is temporarily unavailable or the clients 504, 506 go offline. For example, applications running on clients 504 and 506 can continue to operate offline when the user is on a bus, train or plane, and when network connectivity is unavailable. As described in detail below, once the network connection is reestablished, data changes made at the clients 504, 506 are synchronized with the XML file system 512 in the server-side data center 502.

As noted above, the present invention provides a programming language that allows developers to create applications of the highest level of abstraction. In a practical embodiment, these programming languages include process XML language, user interface (UI) XML language, and application package XML language. Application code written in these programming languages is suitable for being represented as XML structured data and stored in XML documents. In the example illustrated in FIG. 5B, process XML document 516, user interface XML document 518, and application package XML document 520 include application code written in these programming languages, respectively. Thus, an application may be defined in one or more XML documents maintained at server-side data center 502. In addition, an application may typically use data documents, such as data XML document 522, which is also maintained at server-side data center 502. These XML documents 516-522 can be connected on demand by clients 504, 506 to allow applications to be executed using the XML virtual machine 510.

In one embodiment, the UI XML language is used to define the "view" of the application in the MVC design paradigm. In this regard, markup languages were originally developed to describe the layout of web pages so that pages can be rendered by a web browser. The structural nature of markup languages allows the appearance of web pages to be modified without affecting the implementation of the web browser or other related technologies. In this regard, the UI XML language defines the appearance and behavior of an application user interface according to a schema that conforms to XML syntax. Using the UI XML language, developers can create applications with the same graphical elements (eg, menus, toolbars, drop down boxes, etc.) present in common desktop applications. Since user interface logic does not rely on specific client-specific methods or describe its implementation, the UI XML language is suitable for developing user interfaces that operate across different platforms. In addition, the user interfaces and operations described in the UI XML language describe these elements according to the high level abstracted XML syntax according to the MVC design paradigm. Thus, user interfaces and operations described in the UI XML language can be easily modified or modified without affecting other systems. The ability to transform the UI XML language allows an application's functionality to be customized with one or more variables. For example, variations may be defined to reduce or eliminate certain aspects of application functionality that depend on the type of device used. As another example, the variant may be defined in the UI XML language to remove or limit any functionality that relies on user access credentials or localizes the application to other languages and / or markets.

In one embodiment, the process XML language is used to define an "controller" component of the application in the MVC design paradigm. In this regard, the process XML language allows developers to describe the logic of an application in a set of process steps. Each process step includes one or more operations that are approximately the same as the instructions and / or method calls of a traditional programming language. In the MVC design paradigm, process XML language is used as the controller or glue between the user interface ("view") logic and the XML data ("model"). Thus, aspects of the present invention allow application logic to be described using a process XML language at a higher level of abstraction than traditional programming languages. In this regard, the user interface logic ("view") is completely separate from the process XML logic ("controller"). As a result, data handling functions involving multiple application code in existing systems are handled automatically by the present invention. In particular, using process XML language, intelligent data bindings can be defined between the view logic and the data model. When running applications, I / O (input and output) or data to the local temporarily stored data model and to remote file systems and remote listeners are automatically processed by the network operating system. Because developers do not provide data handling logic, applications created using process XML language are often developed faster and contain less application code than traditional applications. As described in detail below, the process XML language provides other advantages in creating and deploying applications in a networking environment, in addition to those described with reference to FIG. 5A.

In addition to the languages described above, application package XML languages are also provided. The application package XML language allows developers to describe the resources used by an application. In this regard, UI and XML documents that define the functionality of the application can be identified in the application package. Logic in the application package allows developers to package and distribute the application's resources to the client in a controlled and secure manner. Moreover, the use of an application package allows multiple instances of the application to be created by a method that enables the XML virtual machine 510 to enable intra-application security.

In one aspect, the present invention provides improved methods for distributing applications and software updates in a networking environment. Using existing systems, an application is typically distributed in an executable format that, when executed, "installs" the application on a computing device. Executable files represent application logic with machine instructions specific to a particular computing platform. Thus, an executable file is a memory intensive representation of an application that consumes a relatively large amount of bandwidth when deployed in a networking environment. Thus, complex and resource intensive systems are required to distribute and install applications using executable files.

Improved methods of distributing applications and software updates over a network are incorporated into the network operating system. Applications that can be used with the network operating system are not "installed" on the client computing device using executable files. Instead, the present invention allows application logic to be represented entirely in XML structured data. Once the client establishes a network connection, the application represented by one or more XML documents can be obtained automatically from the service provider, who can provide the XML documents from a local / private server on the Internet or from any web server. . Thus, a coalescing framework is provided for distributing applications to clients over a network. Also, updates such as "patches" and more recent versions of the application may be automatically propagated to the client. In this regard, since application logic is represented in an XML document that is automatically distributed as a network service, modifications to the XML document are also propagated to clients as a network service. In a network operating system environment, application logic can be synchronized over the network in the same way as other data. Since the XML virtual machine 510 and the XML file system 512 are configured to synchronize data and manage changes through transaction handling, changes to the applications can be performed in a collaborative manner in real time. For example, applications maintained in a shared folder can be opened and executed on the client 504. At the same time, the user associated with the client 506 can modify the application logic and allow the changes to propagate automatically to the client 504. Changes to the application logic can be implemented in real time, and thus can be easily observed at the client 504 when a change occurs.

As described above with reference to Figures 5A-5B, an XML representation of an application is distributed by a service provider and executed on a client using an XML virtual machine. As a result, clients can continue to run applications "offline" without requiring runtime processing from the server side. In this case, XML documents representing one or more applications are temporarily stored in memory on the client. The XML virtual machine can access these temporarily stored XML documents to continue running applications without having a network connection. Furthermore, data updates that occur while offline are also temporarily stored and sent to the server when the network connection is reestablished.

In particular, the present invention provides network operating system services without requiring virtualization of computer resources. In this regard, a number of techniques for virtualizing computer resources are being used to provide network services, such as "cloud" storage. Generally speaking, these virtualization technologies abstract the computer resources typically associated with a server away from underlying platforms. Abstracted resources are typically encapsulated in a platform independent interface suitable for connection from the network. In this regard, computer resources that can be abstracted include applications, hardware, desktops, machine operating systems, and the like. However, complex systems are required to abstract and encapsulate computer resources in this way. For example, a virtualization layer may be required that simulates the underlying hardware of the server and at least affects performance. In addition, these virtualization technologies promote a server-centric model that moves the location where resources are implemented and executed to the server side. When network services are provided to a growing number of users, the increased processing and other demands placed on the server cannot be measured. Thus, the use of virtualization technologies to implement network services may require an integrated data center that requires oversupply of servers to ensure that the service is available on demand. In addition, because application logic runs on a remote server and not directly on the client, virtualization technologies consume more bandwidth and result in a slower user experience. If the network connection goes down or the client goes offline, this also makes the application unavailable.

The implementation of network services without virtualizing computer resources offers many advantages. In this regard, a more scalable structure is provided that allows network services to be accessed by a constantly growing number of users. By using XML virtual machines running applications on the client side, processing and other resources from clients can be utilized to the fullest. This implementation provides a more scalable architecture, in which unique involvement exists between the number of users connected to the network service, bandwidth usage, processing power, and other resources available from the client side to execute application logic. Because. In addition to being more scalable, applications running on a client using an XML virtual machine allow for easy connection by users while the application functionality is "offline". When the client is "offline", applications and user data represented in one or more XML documents may be stored in the client side cache. Thus, all application logic can be executed using data that is available and in the cache, regardless of whether there is an active network connection. However, the application cannot access network resources while "offline" and it is necessary to reestablish the network connection to implement all the functionality of the application. In contrast, the "offline" functionality provided when network services are implemented using virtualization techniques is further limited. In this regard, some existing network services implement an "offline" mode that can continue to interact with applications that were connecting to the network service. However, to provide this functionality, other low-level representations of executables or applications are distributed and installed on the client. If the user is "offline", the low-level representation of this application is run locally. However, installing applications on the client to provide this "offline" functionality may not be feasible or convenient. For example, a resource constrained computing device may not have enough storage to install a low level representation of an executable or other application. More generally, the functionality available on the client without an active network connection is limited to locally installed applications. However, the client may not have enough computing resources (storage, memory, bandwidth, etc.) to install the desired application using an executable or low level representation of the application.

In one aspect, the present invention implements improved methods for connecting to network services via mobile, wireless or unstable networks. Those skilled in the art will appreciate that mobile or wireless networks are less reliable and bandwidth limited compared to wired networks. The provision of a programming language to express application logic with an XML virtual machine 510 configured to automatically perform XML structured data and repetitive data handling functions results in very compact and memory efficient applications. In this regard, when implementing application logic, applications may share the functionality and reuse objects of the XML virtual machine 510. As a result, the distribution of applications available to the network operating system consumes some bandwidth as compared to existing application distribution systems. In addition, the present invention allows XML representations of applications to be maintained in a client-side cache and executed locally using the XML virtual machine 510. Application logic and data can be stored locally locally, eliminating the need for a persistent network connection. Instead, the present invention is well suited to providing access to network services over a wireless network where network connectivity is intermittent. In addition, because the applications are run locally, more reliable network services can be provided that guarantee service. For example, the present invention is also well suited for providing enterprise class applications as a service of a network such as the Internet. In this regard, those skilled in the art will appreciate that enterprise-grade applications need to be accessible within an enterprise even if the network connection is temporarily unavailable or the quality of the Internet connection affects the network connection. The invention described here solves this problem.

Client-side components of the network operating system

Those skilled in the art will appreciate that XML is an extensible language that provides the basis for the creation of additional languages. XML documents have a hierarchical tree structure, where the root of the tree identifies the document and the other nodes of the document are derivatives of the root. Nodes in the tree may contain document content as well as data defining the structure of the content. In addition to the syntax imposed by XML, elements and their associated attributes can be defined to set other semantic constraints on the structure and content of an XML document. In one embodiment, the present invention may implement schemas and terms that apply additional semantic restrictions on those added by XML. Using the XML languages provided by the present invention, developers semantically express the logic of an application according to the MVC design paradigm.

The MVC design paradigm was first implemented in the Smalltalk programming language and subsequently used in other engineering contexts. Those skilled in the art can appreciate that the MVC design paradigm is merely a representation of a general structural paradigm for separating functionality into layers. Thus, the MVC design paradigm has been implemented to remove dependencies and provide platform independence in various contexts. As an example, existing systems that store HTML data, collect dynamic web page content, and render web pages are often described as stuck in the MVC design paradigm. In addition, development environments that created Web applications can separate functionality into layers according to the MVC design paradigm. In this context, the graphical user interface of Web applications has been separated from the data model to support the development of modular applications. However, these existing systems implement functionality and use a more domain specific underlying data model than the present invention.

Unlike existing systems, aspects of the present invention allow all kinds of applications to be created according to the MVC design paradigm. In other words, the separation of the user interface from the logic and underlying data model is not limited to web applications, web pages, and the like. Multi-instance applications in which each instance potentially supports multi-views can be created and run in a network operating system environment. Each of these application instances also manipulates data from the common data model. This greatly simplifies application development by eliminating the need for developers to set up and access data from the data model, and provide programming logic to manage synchronization and user interface ("views") and data exchange between data models.

6A-B, an example process and UI XML documents that can be used to describe aspects of the present invention can be described. 6A shows an example process XML document 600 (“MyTasks.xml”) that provides a semantic description of the controller logic for the “MyTasks” application. As described in FIG. 6A, the MyTasks.xml document 600 includes a trigger 602 defined in an “<trigger>” XML element. This trigger 602 maintains a set of attributes including view, component, event, and step attributes. Moreover, application logic written in the process XML language can define a series of process steps. In this example, MyTasks.xml document 600 includes a plurality of process steps 604-610 described by "<step>" XML elements. As shown in FIG. 6A, two attributes are associated with each process step 604-610 that includes a numeric attribute (“id”) and a name attribute. Within each process step, at least one task is defined. As an example, process step 604 associated with the name attribute "Initialize Application" includes three operations 612-616 described by "<operation>" XML elements.

FIG. 6B shows an excerpt from a UI XML document (“MyTasks_gui.xml”) that provides a semantic description of an exemplary “view” logic for the MyTasks application. As described in FIG. 6B, the MyTasks_gui.xml document 650 includes two button components 652, 654 described by a “<button>” XML element. Each button element maintains a set of attributes, including name, text, and width attributes. In addition, the MyTasks_gui.xml document 650 includes two input components 656 and 658 described by "<input>" XML elements. In this example, input components 656 and 658 maintain a set of attributes including name, width and height attributes.

Upon launching the application, aspects of the invention that act as XML virtual machines can begin to interpret the MyTasks.xml document 600. In one embodiment, rather than being compiled entirely before execution, the application logic is interpreted one statement at a time. However, in other embodiments, application code written in the XML languages provided by the present invention may be compiled into executable code or byte code. In this example, MyTasks.xml document 600 defines a trigger 602 that identifies a process step 606 in the application to be executed in response to activation of the trigger. Initially, in an example embodiment, when the XML virtual machine begins to interpret the MyTasks.xml document 600, the trigger 602 causes the flow to be directed to the appropriate process step 606 in response to the activation of the trigger. Trigger 602 is registered.

In the MyTasks.xml document 600 shown in FIG. 6A, the application defines a basic process step 604 with the name attribute " Initialize Application " to which the control flow will be directed when triggers are registered in the application. Task 612 with name attribute "open" and value attribute "apps / mytasks_gui.xml" is the first task in Initialize Application process step 604 to be executed. Execution of the Open task 612 causes the view of the application represented by the MyTasks_gui.xml document 650 to be interpreted and rendered on the computer display. In this example, the view of the application includes components 652-658 that are semantically defined in the MyTasks_gui.xml document 650. When the MyTasks_gui.xml document 650 is opened, execution proceeds to task 614 with the name attribute "action" and the value attribute "#MyTasks". Generally speaking, execution of the Action task 614 causes the button component 654 to be hidden from view when the MyTasks_gui.xml document 650 is opened.

7A-C, an example graphical display 700 associated with the MyTasks application is described. In particular, the graphical display 700 shown in FIG. 7A includes a Button 1 component 702 and a Button 2 component 704 corresponding to the button components 652-654 semantically defined in the MyTasks_gui.xml document 650. It includes. The graphical display 700 also includes an Input3 component 706 and an Input4 component 708 corresponding to the semantic description of the input components 656-658, respectively. In this regard, the graphical display 700 of FIG. 7A represents a visual depiction of the MyTasks_gui.xml document 650. As described above, when the MyTasks application is started, the process logic in the MyTasks_gui.xml document 650 causes the Button2 component to be hidden. Thus, Button2 component 704 is shown in phantom in FIG. 7A to indicate that Button2 component 704 is initially invisible to the user after execution of Action action 614.

Generally described, an example MyTasks application is set up to display a list of task descriptions stored in a "data / tasks.xml" document. More specifically, when the application is started, the task descriptions are displayed in the Input3 component 706 by default. In one aspect, the user can modify the task list by interacting directly with the Inpu3 component 706 and changing the items of the task descriptions. In another aspect, the user can enter a new task description into the Input4 component 708 and select the Button1 component 702 to activate the trigger 602. If a valid input is received, the new task description is added to "data / tasks.xml" and automatically displayed by the Input3 component 706. Conversely, if the user merely selects Button1 component 702 without providing any input to Input4 component 708, Button2 component 704 is displayed with the phrase requesting that the user provide a valid task description.

Referring again to FIG. 6A, task 616 with name attribute "bind" and value attribute "data / tasks.xml" is the next task to be executed in Initialize Application process step 604. Generally speaking, execution of Bind task 616 causes Input3 component 706 to be a data binding component that displays a list of task descriptions. In particular, the logic provided in Bind task 616 and associated component elements 618 bind the Input3 component 706 to the list of task descriptions represented in the "data / tasks.xml" document. In this example, the task is defined as an element that maintains the associated description attribute in the document "data / tasks.xml". The logic provided by component element 618 selects the "/ tasks / task / @ description" attribute of the task element to display in Input3 component 706. As shown in FIG. 6A, the Bind task 616 is the last task executed in the Initialize Application process step 604.

Referring now to FIG. 7B, the state of the graphical display 700 following execution of the Bind task 616 is described. In this regard, FIG. 7B shows the same button and input components 702-708 described above with reference to FIG. 7A. However, after execution of the Bind task 616, a set of task descriptions are displayed by the Input3 component 706. In particular, the Input3 component 706 is bound to the description attribute of the task elements defined in the "data / tasks.xml" document. Thus, after the Bind task 616 is executed, the values assigned to these task descriptions, represented in the data model (eg, document object 710), are displayed in the Input3 component 706.

Executing the Initialize Application process step 604, execution of the application logic represented in the MyTasks.xml document 600 does not resume until the trigger is activated. In this example, the MyTasks.xml application defines a trigger 602 that directs execution flow to process step "2" when the Button1 component 702 experiences a "select" event. Thus, the trigger directs the flow of execution to process step 606 named "Press Button" in response to the selected Button1 component 702. In this example, task 602 with name attribute "decision" and value attribute "# MyTasks # input4" is the task to be executed in Press Button process step 606. Generally speaking, the decision task 620 performs a test to determine what text was entered into the Input4 component 708 when the Button1 component 702 is selected. The logic in the "<when>" XML element 622 directs the execution flow to process step 608 if text has been entered in the Input4 component 708 when the Button1 component 702 is selected. Conversely, decision operation 620 directs execution flow to process step 610 if no text was entered in the Input4 component 708 at the appearance of the trigger.

In an example, if text is entered into the Input4 component 708, the execution flow proceeds to an "Add Task" process step 608. Thus, task 624 with name attribute "change" and value attribute "data / tasks.xml" is the next task to be executed. Change task 624 causes a new task element with the appropriate descriptive attributes to be added to the "data / tasks.xml" document. In this regard, the " <store> " XML element 626 in the change operation 624 provides logic to cause the text entered in the Input4 component 708 to be stored in the description attribute of the new task.

Accordingly, referring now to FIG. 7C, the state of the graphical display 700 following the input of a new task and the selection of the Button1 component 702 is shown. Thus, FIG. 7C includes the same components 702-708 described above with reference to FIGS. 7A-7B. In this example, the user has entered the text "purchase airline tickets" in the text area provided by the Input4 component 708. The modification task 624 described above uses the corresponding document object 710 to add the value of this task description to the "data / tasks.xml" document. Since the Input3 component 706 is bound to the selection of the explanatory attributes affected by the change operation 624, the list of tasks displayed by the Input3 component 706 is automatically updated in the document object 710. In other words, developers do not have to provide application code for synchronization and data exchange between the Input3 component 706 and the data model.

In one aspect, the user can enter a new task description into the Input4 component 708 and select the Button1 component 702 to update the task list. In addition, the user can directly interact with the items displayed in the input3 component 706 to modify the task descriptions. As an example, a user may delete the "update presentation" task currently being displayed by the inpu3 component 706. Since data bindings are defined, deletions are automatically propagated to the "data / tasks.xml" document. In this regard, one or more components and / or local or remote applications may be data listeners for task descriptions represented in a "data / tasks.xml" document. Each local data listener is notified and updated by the document object 710 in response to the " update presentation " task being deleted. In particular, the deletion of tasks propagates into underlying data models without requiring developers to provide application code to handle data updates and then propagates to any listeners over the network.

Referring again to FIG. 6A, if no text is input to the Input4 component 708 when the Button1 component 702 is selected, the execution flow proceeds to a "Show Button" process step 610. Thus, task 628 with name attribute "action" and value attribute "#MyTasks" is the next task to be executed. Generally speaking, execution of this Action task 628 causes the Button2 component 704 that was initially hidden (FIG. 7A) to be displayed. As indicated in the MyTasks_gui.xml document 650, the Button2 component 704 displays a text string requesting the user to provide a valid task description.

As will be appreciated by those skilled in the art, the MyTasks application described with reference to FIGS. 6A-7C is a very brief example of one application that can be used to illustrate aspects of the present invention. Additional applications can be created and run within the network operating system environment. Accordingly, the examples and descriptions that refer to the MyTasks application herein should be interpreted as illustrative.

Programming languages used to develop modern applications (C ++, Java ™, Python ™, etc.) include user interface components that are created and maintained in the application's process logic. In other words, the developer explicitly provides the logic to create and set the data on the user interface components. The developer also provides code in the application's process logic that listens for events that affect the user interface of the application or at least monitors data changes. These event listeners allow data changes to be maintained between the application's user interface and domain specific data structures. However, the input / output between data structures in the application's user interface is not standardized. Thus, the presentation of data on the application's user interface is strongly coupled to how the data is represented within the data structure. As a result, modifications to the user interface or data structure may affect other aspects of the application.

The network operating system provides an automated communication path between the user interface and the underlying data model that supports the execution of applications that adhere to the MVC design paradigm. In this regard, developers can define bindings between user interface components (often referred to as controls or widgets in other programming environment languages) and underlying data models. Coordination of data updates affecting components and data updates to the underlying data model is managed by the present invention, thus simplifying application development. As explained in the description of the MyTasks application, when the data represented in the underlying data document changes, any data bound components that listen to the data change are automatically updated. More specifically, bind task 616 of the MyTasks application provides application logic to bind Input3 component 706 to a set of data represented in the data model. Thus, deletion from the underlying data XML document of the "update presentation" task is automatically propagated to listening components, including applications and components that are listening to the same document over the network. Data bindings also enable synchronization and data exchange between user interface components of local and remote clients over a network. As an example, change task 624 of the MyTasks application provides application logic to update the underlying data document with text entered into Input4 component 708. In this regard, the Input3 component 706 is listening to changes to the underlying data document. The visual display of the Input3 component 706 is updated when text is entered into the input4 component 708 and the trigger 602 is activated. In this example, the combination of data binding and change operation 624 enables synchronized exchange of data between user interface components.

As mentioned above, the binding provides an automated communication path between the user interface components and the underlying data model. In one aspect, the present invention allows binding to be shared and / or transferred between user interface components. This aspect of the invention is represented in Figures 8A-B, which shows components 800, 850 set up to display different visual representations of a user's file system folders. In particular, FIG. 8A shows component 800 configured to display a user's folder in a tree structure. When the user generates an input requesting that the folders be displayed in a list, the data binding of component 800 to the underlying data model is passed to component 850, and the state of component 800 is also passed. This example illustrates that the present invention removes the dependency between the representation and processing of data from the establishment of the data model. In addition, delivery and sharing of data bindings not only provide an automated communication path between application layers in accordance with the MVC design paradigm, but also provide an improved platform for applications under development.

The present invention provides a set of user interface components (eg, buttons, input boxes, drop down boxes, display panel, etc.). In order to enable application development, the standard framework allows applications to be built from related user interface components. In this regard, user interface components can inherit properties from a parent component using the UI XML language, and thus can be combined to represent more complex user interface elements. As a result, the application may include a set of related components organized in a hierarchical structure in which each component recognizes the associated document. In another embodiment, a single user interface component may be defined to represent the entire view of the application. In addition, a component API (Application Programming Interface) is provided that allows developers to create new user interface components for use with the present invention.

In one aspect, the present invention supports the development of process-oriented applications using XML language. In this regard, each process step in the MyTasks.xml document 600 represents a portion of a process execution flow. Tasks within a process step can define state changes in a running application. Communications between processes are supported through controlled connections to data describing the runtime state of the application and through the use of messaging ports. Developers can refer to views, components, and other runtime variables with expressions using globally-named objects. In this regard, an expression language or general method of referencing and manipulating objects is provided. Generally speaking, expressions and process XML languages collectively abstract the complexity of running multi-instance applications. Instead, developers can create an application as if it were present in a single instance run. As the MyTasks.xml document 600 illustrates (FIG. 6A), expressions are structured to be compatible with XML syntax and are scoped or tagged for use within other programming languages. Once the expression is evaluated, the XML virtual machine performs the task of identifying, merging, and manipulating the requested data according to the received expression. As a result, globally named objects can be used by developers in application code even if multiple runtime instances of the application are executed.

The present invention provides a client side component implemented with a plurality of "classes" from which "objects" will be instantiated. In other words, client-side components can be implemented using a programming language such as JavaScript that uses object-oriented programming features. In other embodiments, the invention may be implemented using a non-object oriented language or other language, such as C programming language, in which the objects may be represented as objects. As will be appreciated by those skilled in the art, objects created from a class typically include methods that encapsulate or hide an algorithm that implements the functionality of that object. Instead of disclosing this implementation detail, the objects provide interfaces that other modules can abstractly access to their functionality. Thus, functionality implementing the XML virtual machine in accordance with one embodiment of the present invention exists in the context of objects using object orientation and inheritance.

As mentioned above, the client-side component acts as an XML virtual machine running applications written in languages that adhere to XML syntax. In a practical embodiment, the XML virtual machine may include a process modeling language (eg, process XML language), a user interface modeling language (eg, UI XML language), and an application package modeling language (eg, application package XML language). ) Is set to execute the application code described semantically. In particular, the XML virtual machine can be extended to understand additional XML languages or XML-based applications that provide functionality not described herein. Also, instead of executing programming logic using the XML languages described herein, other embodiments are possible. For example, JavaScript APIs or libraries can be used to build applications that implement the same functionality. Thus, the use of XML-based languages is merely exemplary, and the present invention may also be implemented using traditional programming languages.

At any time, the application being interpreted by the XML virtual machine may be understood to be in a particular execution state. The process XML language allows developers to define conditions for transitioning between states. First of all, the XML virtual machine: (1) defines a set of runtime variables / objects that describe the state of a running application, (2) implements logic to drive when a transition occurs in an application state, and (3) an application. By providing low-level constructs that implement stateful changes, we implement the functionality to manage state transitions.

Referring now to FIG. 9, aspects of client-side components, classes, and objects that implement the XML virtual machine are described. The client-side component includes a plurality of "managers" or objects that are instantiated at startup of the client-side component of the network operating system and that remain active during the user session. As noted above, objects provided by a client-side component in accordance with an exemplary embodiment utilize object orientation and inheritance. In this regard, the system context object 902, which acts as a place holder where managers and other objects are embedded at runtime, is instantiated. Accordingly, the system context object 902 includes an application manager 904, a process manager 906, a view manager 908, a transaction manager 910, a document manager 912, and an event manager 914. It can be used to create instances of managers shown in.

Each manager typically performs certain tasks exposed through an interface accessible from the system context object 902. Thus, other objects implemented by the present invention may invoke and use the manager's functionality to perform the desired task. For example, process manager 906 may be called to instantiate a process object that is preparing to execute the application's process code. In another aspect, managers allow controlled instance creation and communication between objects that provide the basis for internal application and internal process security. Although the description is provided herein with reference to specific managers and associated objects that the manager has accepted, those skilled in the art will appreciate that encapsulation of functionality into a particular kind of manager is exemplary. In other embodiments, the functionality described herein in connection with specific managers and their corresponding objects may be performed without encapsulation, or encapsulated in a manner different from that described. In addition, the object-oriented programming languages and features described herein are exemplary only, as other tools may be used without departing from the scope of the claimed subject matter.

As shown in FIG. 9, the client-side component includes an application manager 904 that provides logic to manage the lifecycle of the application. In this regard, the functions are exposed by the application manager 904 to create, open, and terminate applications. The application may be represented internally as an application object that "registers" with the application manager 904. Once the application is scheduled to run, the application manager 904 can be called to create the corresponding application object. Thus, the application manager 904 creates and accepts references to all activated applications in the system.

As mentioned above, the attributes of one or more applications may be semantically described in an application page by the developer using the application package XML language. The attributes described in the application package contain references to resources and system settings to be used by the particular application to be executed. The resources identified in the application package include XML documents that provide a semantic description of the application view and process logic. In one aspect, the application manager 904 is configured to abstract the information in the appropriate application package and obtain the identified resources if the application is scheduled to run. In another embodiment, any XML data resource, including UI and process XML documents, may be embedded directly into the application package. In another aspect, functionality that allows applications to continue execution when the client is "offline" is implemented by the application manager 904. In this regard, a suitable application package may be referenced by the application manager 904 that identifies the resources used by the corresponding application. Thereafter, any resources that are not temporarily stored locally are identified and obtained from the appropriate service provider.

 The process manager 906 shown in FIG. 9 is responsible for the creation and acceptance of internal process objects used to execute process steps in an application. As mentioned above, application logic written in the process XML language defines a series of process steps, each containing one or more tasks. The process object created and received by the process manager 906 is responsible for loop through and invoking one or more lower level structures or task handlers. Unlike traditional platforms, the conceptual basis of the network operating system is based on process oriented tasks for modeling lower level structures. For example, higher level structures such as model workflows, product life management, user collaboration, and the like are built from this lower level structure. By way of example, a set of task handlers that model the low level structure provided by the present invention include, but are not limited to, open task handlers, bind task handlers, change task handlers, decision task handlers, and the like. In addition, a task API is provided that allows developers to define additional task handlers. In this way, the XML virtual machine can be extended to support and execute additional lower level structures. On the other hand, tasks that can be used in an application are limited to tasks generated according to task APIs or provided by the present invention. As a result, only a limited and well-defined set of tasks can execute application logic, which severely limits the user's ability to create malicious software or to implement malicious functionality. On the one hand, because there are a limited number of ways to manipulate XML documents, a relatively small number of tasks need to be provided. Since XML is a very general language, any application or domain can be described using that language. Thus, the process XML language and corresponding tasks provided by the present invention can describe any number of process logic and can be used to describe any kind of application.

According to one embodiment, an instance object that tracks the "runtime status" of a running application or instance is provided by the present invention. Those skilled in the art will appreciate that the runtime state of a running application can continue to evolve as logic is executed. An instance object tracks and manages the runtime state of a running application and provides context to other objects used to implement the XML virtual machine. Thus, instance objects combine the meaning of a task into the execution of processes and the tasks associated with them. As a result, even if the runtime state of the application instance changes constantly, task handlers are supplied with data describing these changes. In this way, the present invention supports the dynamic execution of application logic using stateless process objects. In other words, even if there are multiple instances of the application, only a single version of the application code is needed, thus saving memory.

As shown in FIG. 9, the client-side component includes a view manager 908 that is responsible for tracking the "view" or user interface associated with the running application. Methods are provided by the view manager 908 to create internal view objects that are used to render and update the user interface of the application. In accordance with the MVC design paradigm, the user interface of an application may be described semantically using UI XML language. Thus, components and other graphical attributes of the complete user interface of the application can be represented in a UI XML document. View objects instantiated and accommodated by the view manager 908 are used to render the user interfaces semantically described in the UI XML document. In one embodiment, the rendering of the user interface may be performed through a series of XML transformations. However, one skilled in the art can understand that the user interface can be rendered without performing XML transformations and the foregoing description should be interpreted as illustrative. In any case, view manager 908 is set up to create new view objects and accept a reference to all activated views in the system.

As shown in FIG. 9, the client-side component includes a document manager 912 that is responsible for creating instances of document objects and accepting references to document objects. As mentioned above, XML documents are a data model that serves as a common data source in a network operating system environment. Application logic, system settings, application state, etc. are also represented in XML documents. In one aspect, document manager 912 is responsible for allowing documents to be loaded or temporarily stored in memory on the client computer. Thus, document manager 912 may interact with other managers, such as a communication manager (described below), to obtain documents. Documents can be obtained from a remote network location using a channel that can be created to access documents maintained on a communication channel or nonvolatile memory on a local hard drive or on a client computer. In another aspect, document manager 912 acts as a client-side cache that tracks each document loaded into memory on the client computer. Once the document is acquired locally, an internal document object can be instantiated that provides a structured object-oriented representation of the document. In this regard, document manager 912 accepts references to all document objects in the system and exposes, among others, methods for creating, retrieving, storing, and renaming XML documents.

The event manager 914, shown visually in FIG. 9, serves as a trigger event bus that allows aspects of the XML virtual machine to execute application logic in response to activation of the trigger. The process object may use a notifier object that registers a trigger as a listener in the event manager 914. Other objects in the system, such as component objects, often register themselves directly with the event manager 914 as a listener. First of all, the Notifier object receives and stores data identifying process steps in the application to be executed in response to an activated trigger. In addition, the data provided by the Notifier object associates a trigger with an originating object (ie, often a view or component object). On the other hand, the event manager 914 causes objects (ie, view or component objects) to push or notify registered listeners when the trigger is activated. In this example, the component object notifies the event manager 914 and passes the data. In response, event manager 914 performs a look-up that identifies listeners for the active event. The appropriate notifier or other listening objects can then be alerted and provided with data that allows the application execution to proceed to the appropriate process step. As described in detail below, individual application instances may each use the same set of triggers and notifier objects. The provision of event manager 914 and related systems configured to reuse the same resources in this way reduces the memory used while improving performance.

As used herein, "trigger" indicates the presence of a defined triggering that causes application code to be executed. Thus, in the example process XML document 600 described above with reference to FIG. 6A, activation of the trigger 602 causes certain process steps defined in the application code to be executed. Compared to existing systems, triggers implemented by the present invention do not normally activate in the presence of data updates. In other words, in addition to specifying tasks such as data binding, developers are not required to provide logic to manage input and output from the application user interface to the data model. Instead, data updates are managed by the present invention by a separate data update notification event bus and do not correspond to activation of a trigger. As described in detail below, aspects of the present invention provide a separate event bus implemented in a document object that automatically handles the propagation of data updates for components and objects.

Transaction manager 910, also shown in FIG. 9, provides an interface for creating and propagating transactions used to update the content of an XML content. Thus, if a change to the data model is made, this results in a transaction. In this regard, a transaction may be represented as an XML data fragment that represents a relative change and includes data used to implement or restore changes to the data model. For example, in the MyTasks application described above with reference to FIG. 6A, the change task 624 of adding a task to the underlying data XML document results in the creation of a transaction. Data updates reflected in a transaction can be persisted in the data model as well as any remote listeners. In one embodiment, the transaction manager 910 not only identifies the order in which the transactions were created, but also identifies and time stamping data as to when the transaction was created, which could be used to "roll back" the data update represented in the transaction. Include.

Referring now to FIG. 10A, an application start routine 1000 for performing processing to open an application package is described. The application start routine 1000 may be performed in response to a user who generates a command to start an application. As noted above, aspects of the present invention can provide a desktop environment in which a user can launch applications through selection of menu items, icons, and the like. In response to receiving this type of command, a URL identifying a location associated with an application package, XML document, or binary file may be passed to a data type recognizer within system context object 902. . As described in detail below, data type recognizers are used in various ways to identify actions and associate them with a particular type of documents. In any case, the application start routine 1000 may be performed if the data type recognizer determines that a document corresponding to an application package (eg, an application package XML document) has been opened.

In the application start routine 1000 shown in FIG. 10A, the application manager 904 is used to instantiate the application object of block 1002. Multiple application objects, each representing a different application, are instantiated and housed in an application manager 904. In this iteration through the application start routine 1000, for example, a first application object representing a word processing program can be instantiated. In another iteration through the application startup routine 1000, a second application object representing another program (eg, an email program) may be instantiated. By controlling instance creation and access to application objects, process logic associated with one application cannot access internal objects (eg, view objects, instance objects, process objects, etc.) associated with another application. Thus, when executing the process logic of the word processing program, the view object associated with the email application package is not accessible. As described in detail below, the use of an application manager 904 to instantiate and accept application objects is part of a larger framework provided by the present invention that ensures both internal application and internal process security.

At block 1004, resources of the open application specified in the corresponding application package are obtained. The logic in the application package formed in accordance with the present invention provides a complete blueprint of resources and application configuration. Thus, the application package XML document can identify the process and UI XML documents associated with the application, as well as other application resources such as images, data documents, XSLT documents, among others. Resources used by the application, including the application package XML document itself, may be temporarily stored in memory on the client or obtained from a service provider using a communication channel (described below). In addition to resource and configuration management, the application package XML language allows developers to configure application packages in more advanced ways. By way of example only, conditional logic in an application package XML document can be used to implement more fault-tolerant network services where resources are obtained from a failover network location. If the primary network location is not available, the application package can identify alternate network locations from which resources can be obtained. However, this is just one example of how the present invention allows developers to set up an application package using the package XML language.

As described in FIG. 10A, at block 1006, application startup routine 1000 determines whether additional runtime instance (s) of the application are allowed. The application package XML language allows developers to set configurations that limit the number of application instances that can be created. Thus, the decision made at block 1006 may depend on the settings defined in the application package XML. At block 1006, if a determination is made that no additional instances are allowed, the application startup routine 1000 proceeds to block 1008 where an instruction to start an application that does not allow additional instances is processed. In this regard, instruction handling at block 1008 may include refreshing an existing runtime instance of the application. Additionally or in another embodiment, command handling may include notifying the user via a dialog that additional instances of the application are not allowed. Then, when processing the command, the application start routine 1000 proceeds to block 1014, where it ends.

. On the other hand, if the decision made at block 1006 allows for an additional instance of the application, the application start routine 1000 proceeds to block 1010. At block 1010, an instance object is instantiated that tracks and manages the runtime state of the launched application. Once process and view objects are created, aspects of the present invention associate these objects with their corresponding instances. The instance object instantiated at block 1010 maintains structures that track process and view objects, aliases, and other runtime variables. Thus, process and view objects associated with this application instance are well known to the instance object. Through controlled instance creation and reference to objects, a localized relationship hierarchy can be established that defines the boundaries of the application instance. As described below, this framework associates process and view objects with corresponding instances and restricts access to these objects outside of the localized relationship hierarchy.

The context provided by the object instantiated at block 1010 allows functionality regarding the application runtime state to be implemented. In one aspect, the instance object instantiates and accepts a local expression engine that evaluates expressions encountered in the application code being interpreted. The process object can use the local expression engine that the instance contains to evaluate the corresponding instance object and expression. In addition, the instance object instantiated at block 1010 may be provided when executing tasks to combine semantics of the task with execution of process logic.

As detailed in FIG. 10A, at block 1012, the application object instantiated at block 1002 may be used to open and start the execution of the process and view logic of the application. Routines for opening and starting the execution of logic in processes and UI XML documents are described below and are not provided here. Importantly, every time an application associated with an application package is started, a new instance object is provided to track the runtime state of the application. For example, an application object representing a word processing program provides another instance object each time a word processing application is started. By using an application object in this way, aspects of the present invention can control the connection to objects associated with a running application. The application start routine 1000 then proceeds to block 1004 where it ends.

Referring now to FIG. 10B, the use of an application object to encapsulate applications and provide internal application security is described in further detail. When an application is launched from an application package, the application manager 904 instantiates an application object that provides an encapsulated representation of the application. As illustrated in FIG. 10B, the application manager 904 may instantiate Application Object A 1030 and Application Object B 1032. In one embodiment, an application object may instantiate and accept one or more instance objects. In the example shown in FIG. 10B, Application Object A 1030 may instantiate and accept Instance Object A1 1035, Instance Object A2 1038, and Instance Object AN 1040. Similarly, Application Object B 1032 may instantiate and accept Instance Object B1 1042 and Instance Object BN 1044. In this regard, the one-way arrow between the objects shown in FIG. 10B indicates that the source object from which the arrow originated accepts the destination object identified by the arrow. Thus, an arrow from application manager 904 to application objects 1030-1034 indicates that these objects are accommodated in application manager 904. From the description of FIG. 10B, the relationship between the application manager 904, the application objects 1030-1034 and their corresponding instance objects 1036-1044 becomes clear.

The relationship between the objects shown in FIG. 10B illustrates whether the present invention can guarantee internal application security. Access to application objects is controlled by the application manager 904 that exposes methods for creating, opening, and terminating applications. Once the application object is instantiated, the application manager 904 isolates the application object into a separate memory space. By preventing application objects from sharing memory space, code from one application cannot be injected into or affect the memory space allocated to another application. The application object also provides an encapsulated representation of the application in which internal data associated with the application is hidden. Both application functionality and access to internal data are controlled through the creation of exposed methods. By isolating and encapsulating applications in this manner, internal objects associated with one application (eg, view objects, instance objects, process objects, etc.) cannot be connected to other applications. Thus, when executing code using Application Object A 1030, internal objects associated with Application Object B 1032 may not be connected. Even if the internal data of the application cannot be accessed, the data can be shared using the underlying data model. Thus, if a user has sufficient access rights, the document can be shared by multiple applications. In other words, the internal application security framework provided by the present invention does not prohibit authorized uniqueness of data between applications using the underlying data model.

. Referring now to FIG. 10C, the use of instance objects to implement a localized relationship hierarchy is described in further detail. By defining a localized relationship hierarchy, aspects of the present invention allow multi-instance applications to run securely. The description of FIG. 10C includes an application object 1050 and an instance object 1052. 10C also shows a process object 1054, a view object 1056, a component object 1058, and a dialog object 1060 that are instantiated when an application's process and UI XML documents are opened. In one embodiment, the application object 1050 provides an instance object 1052 when starting the execution of the application. A dotted one-way arrow starting at application object 1050 and pointing to view object 1056 and process object 1054 indicates that these objects were created within a localized relationship hierarchy specific to provided instance object 1052. . In this regard, the instance object 1052 maintains a MiniView manager 1062 and a MiniProcess manager 1064. When the application's process XML document is opened, an instance object 1052 is provided with reference to the resulting process object 1054 tracked using the MiniProcess Manager 1064. Similarly, view object 1056, which occurs when an application view is opened, is provided to instance object 1052 and is received by MiniView manager 1062. Thus, updates to MiniView Manager 1062 and MiniProcess Manager 1064 allow instance object 1052 to track and identify objects associated with a particular application instance.

Through code describing the logic of the application, developers can use globally named objects to define the logic of the application. These globally named objects may be referenced according to the expression language provided by the present invention. However, global names assigned to objects in application code can refer to runtime objects belonging to other instances. For example, the following expression "# MyTasks #" may be used in application code that references view object 1056. In addition, the next expression "# MyTasks # button1" may be used to refer to a component object (eg, a Button) created within the context of the view object 1056 described above. To remove ambiguity and enhance security, aspects of the present invention implement functionality that allows globally named objects encountered in application code to be evaluated with respect to the appropriate instance. In this regard, the evaluation of globally named objects is performed without generating a duplicate process or UI XML documents. Instead, the application's process and UI documents are shared and used to build runtime objects for multiple application instances. As will be clarified below, the implementation of a localized relationship hierarchy provides a basis for identification and / or provisioning of the appropriate instance when expressions are evaluated and access the appropriate view object within the instance.

In the example shown in FIG. 10C, a double arrow is shown between the instance object 1052 and the view object 1056. On the other hand, a double arrow indicates that the instance object 1052 knows that the view object 1056 is associated with this particular application instance. Once instantiated, the view object 1056 is provided to the instance object 1052 and received by the MiniView manager 1062. On the other hand, when an application view is created and the view object 1056 recognizes an instance associated with it, an identifier for the instance object 1052 is supplied. As a result, a suitable instance is identified when an input is received that causes data update or application logic to be executed. For example, component object 1058 may be instantiated when view object 1056 is used to open an application view. The component object 1058 is created in the context of the application view and thus can communicate with the view object 1056. As a result, component object 1058 identifies the appropriate instance object 1052, for example, when providing input that allows a user to execute application code.

 In the example shown in FIG. 10C, a one-way arrow is shown between the instance object 1052 and the process object 1054. In one embodiment, process steps in an application are executed using process object 1052. Through the use and update of the MiniProcess Manager 1064, the instance object 1052 is aware of the associated process object 1054. However, process objects provided by the present invention are stateless between process steps. As a result, process objects are provided with context from a single instance object 1052. In other words, process object 1052 does not recognize the associated instance object 1052 between executions of process steps. However, the process object 1054 may use the services of the expression engine (described below) accommodated by the provided instance object 1052. The localized relationship hierarchy and associated descriptions shown in FIG. 10C illustrate how the present invention can ensure internal process security while still supporting multi-instance applications. Repeating through the tasks in the process step, process object 1054 can only be provided context from one instance object 1054. A framework in which relationships are established so that process object 1054 is fed context from single instance object 1054 allows for strict separation between objects associated with other instances. Thus, when executing application code, process object 1054 may not be able to access objects that are in the localized relationship hierarchy of another instance.

Aspects of the invention may create sub-instances within a localized relationship hierarchy established by parent instances. In this embodiment, the sub instance and the resulting sub view object and sub process objects are created within a localized relationship hierarchy established by the parent instance. The localized relationship hierarchy described by the sub instance can be shown to objects created within the localized relationship hierarchy established by the parent instance. However, runtime objects created within a sub instance do not recognize objects associated with the parent instance or other sub instances. The ability to nest subinstances in a parent instance gives application developers great flexibility in building modular code as well as the ability to use other scopes.

Referring now to FIG. 11, a process start routine 1100 for opening and starting execution of logic defined in process code of an application is described. The process start routine 1100 may be executed when a call is made to open a document including process logic. In one embodiment, the call to open the file may be issued to a data type recognizer that receives a URL from the calling object. The URL passed to the data type identifier may correspond to any kind of document, including but not limited to an application package XML document, a process XML document, or a UI XML document. When opening a document containing process logic, the data type recognizer can cause certain actions to be performed to enable the application to run. In the example embodiment shown in FIG. 11, the data type recognizer determines whether the provided document is a process XML document and allows the operations specific to that type of file to be performed.

The process start routine 1100 shown in FIG. 11 describes two example environments in which a process XML document can be opened. However, the examples provided below should be construed as illustrative, as process XML documents may be opened in other environments without departing from the scope of the claimed subject matter. As described in FIG. 11, process start routine 1100 begins at block 1102 or block 1104. In an example embodiment, the routine 1100 begins at block 1102 where the data type recognizer receives a call to open a process XML document associated with an application package. In this embodiment, the application object provides the previously created instance object received at block 1102 upon invocation. As described in detail below, the process start routine 1100 instantiates a process object that is expected to execute the process steps defined in the process XML document. A reference to this process object may then be provided to the corresponding corresponding instance provided at block 1102 upon invocation.

In another embodiment, the process start routine 1100 begins at block 1104 where the data type recognizer receives a call to open a process XML document representing a standalone application. Applications do not need to be associated with an application package. In this embodiment, the data type recognizer does not receive the instance provided in block 1104 when calling to open the process XML document. Applications configured to be independent in this way do not support multiple instances of execution and allow applications to share at least part of the memory space.

At block 1106, processing is performed by a data type identifier that identifies the file type of the document to be opened. In this example, the analysis performed by the data type recognizer determines whether the document associated with the received call is a process XML document. As discussed above, the data type recognizer may associate the actions with a particular file type. Upon encountering a request to open a process XML document, the data type recognizer is set at block 1108 to call a process manager 906 indicating that a request to open a process XML document has been received.

In decision block 1110, the logic in process manager 906 determines whether the process object for this process XML document is temporarily stored in memory. In one aspect, process startup routine 1100 is responsible for instantiating a new process object when the application is first started. Once instantiated, the logic is implemented by the process start routine 1100 that allows the newly instantiated process object to execute the process step. Process objects can be reused because their state is not preserved. Thus, the same process logic can be used to execute application code from the same instance of other processes embedded in an application package or process XML document. Thus, the process object instantiated when the application is started may be temporarily stored in memory by the process manager 906. If process manager 906 instantiates a process object for this application that is still in memory, the result of the test performed at block 1110 is "Yes" and process start routine 1100 proceeds to block 1120. It will be described in detail below. Conversely, if it is determined that a new process object should be instantiated, process start routine 1100 proceeds to block 1112. Before a new process object can be instantiated, the open process XML document must be available locally. Accordingly, process manager 904 generates a call that is routed through document manager 912 to obtain a suitable process XML document, at block 1112.

In block 1114, it is determined whether the process XML document being requested by the process manager 904 has been loaded into the memory of the client computing device. As discussed above, document manager 912 acts as a client-side cache that tracks each document loaded into memory on the client. If it is determined that the process XML document being opened is referenced in the client-side cache maintained by the document manager 912, the process start routine 1100 proceeds to block 1118, which is described in detail below. Conversely, if the requested process XML document has not been loaded into the client side cache, the process start routine 1100 proceeds to block 1116 causing the document manager 912 to obtain the requested process XML document. More specifically, at block 1116, document manager 912 uses a communications manager (described below) to request that a suitable process XML document is obtained from a network location identified by the provided URL.

If a process XML document is available from the client side cache, a new process object is instantiated at block 1118. In particular, the logic in process manager 904 is used to instantiate new process objects that are supposed to execute application code. The new process object is then registered as a listener in the corresponding process XML document at block 1120. As described in detail below, by registering as a listener to a document in the data model, the object can be notified when a specific data update for the document is performed and take some action.

In block 1122, the Notifier objects are instantiated for each trigger in the application. In particular, parsing may be performed to identify trigger elements defined in the open process XML document. As an example, the MyTasks application defines a trigger 602 (FIG. 6A) that results in a Notifier object instantiated at block 1122. Triggers can be defined as elements in a process XML document with each trigger including view, component, event, and step attributes. The value assigned to the view and component properties identify the application view and / or component on which the trigger will be activated. Similarly, the value assigned to the event attribute identifies the kind of event that will activate the trigger. In addition, the value assigned to the step attribute identifies the process step in the process code of the application to be executed in response to the trigger. For each trigger in the application, the logic in the process manager 906 temporarily stores the data in a Notefire object that can then be used to instantiate the Notifier object and perform a particular process step.

As detailed in FIG. 11, each trigger defined in the application is registered with the event manager 914 at block 1124. In one embodiment, event manager 914 maintains an internal hash data structure that associates a set of trigger data with listening notifier objects. Thus, triggers can be registered by updating the hash data structure maintained by the event manager 914. As described in detail below, the event manager 914 notifies appropriate listening objects and notifier objects when an event occurs that matches a registered event for a component and an event type.

As detailed in FIG. 11, a determination is made at block 1126 as to whether a new instance will be instantiated. When opening a process XML document, an instance can be provided. In particular, the application startup routine 1000 described above instantiates and provides an instance when opening a process XML document. In addition, instances can be provided in different environments to support modular application development and for other processes that share context. In these embodiments, the new instance is not instantiated and the process start routine 1100 proceeds to block 1130, as described in detail below. Conversely, if no instance object is provided, process start routine 1100 proceeds to block 1128, where the instance object is instantiated. In particular, the logic inside process manager 906 generates a call to instantiate a new instance object at block 1128.

At block 1130, a call is made to execute the process step defined in the process XML document. In an actual embodiment, the process object is set to run based on two parameters received by the process system. (1) a provided instance representing the runtime state of the application and (2) an identifier of the process step to be executed. In this regard, the instance provided to the process object may be created in the context of an application package or standalone application. In both embodiments, the process start routine 1100 is configured to provide a process object with a parameter that causes the process object to be reused for multiple instances when executing each process step defined in the process XML document. The process start routine 1100 then proceeds to block 1132, where it ends.

When the process step begins, the control flow is directed to an execute method encoded within the process object. Generally speaking, the execute method loops through and causes each task defined at the process level to execute. In other words, the execute method is an interface to process tasks developed according to the process task API. Thus, the execute method may be called by the process start routine 1100 to execute process step "1" defined in the MyTasks application. In response, the execute method performs processing that may cause Open, Bind, and Action tasks 612-616 to execute within this process step 604.

Referring now to FIGS. 12A-B, an execute method 1200 is described in which tasks are set to be executed at a process step. As illustrated in FIG. 12A, the execute method 1200 begins at block 1202 where a new task within a process step has been identified. In one embodiment, tasks within processor steps are typically identified and executed sequentially. Upon encountering a new task, the expression provided in the value attribute of the task is selected for valuation in block 1203. For example, in the MyTasks application described above, MyTasks document 600 (FIG. 6A) defines an initialize Application process step 604. Within this process step 604, the first task is an Open task 612 with a value attribute "apps / mytasks_gui.xml". In iteration through the execute method 1200, the expression "apps / mytasks_gui.xml" is selected for valuation at block 1203.

The description with reference to FIG. 12 provides examples in which tasks within a process step are executed sequentially. However, aspects of the present invention support asynchronous execution of tasks such that each task in a process step may not execute sequentially. For example, if the first task requests a resource that is only available at a remote network location, other tasks may be executed (not dependent on the result of the first task) while the resource is acquired asynchronously.

As described in detail in FIG. 12A, the selected expression for evaluating at block 1203 is validated with XBind at block 1204. As used herein, an XBind is a data that contains a URL, a base path (e.g., an XPath representation that references an XML fragment within a document identified by a particular URL), and a selection (e.g., an XPath expression of a vox). It's kind. In the example Open task 612 defined in the MyTasks application, the "apps / mytasks_gui.xml" expression is evaluated at block 1204 with the next XBind.

URL = apps / mytasks_gui.xml

Base path = /

Selection =

The URL of this XBind refers to a UI XML document that provides a semantic description of the application's user interface. When the examples provided herein use a URL as a format for identifying resources, this should be interpreted as illustrative. Any system capable of uniquely identifying a resource can be implemented with the present invention. As described in detail below, the network operating system provides protocols and abstractions for connecting to XML web services using an XML file system, a database, and a URL. However, it is contemplated that other protocols were used to identify resource locations other than URLs. The base path of the above XBind is "/" which refers to the root element of the UI XML document identified in the URL. When opening an application view, the base path references a fragment of the UI XML document. In this case, the semantic description of the view logic is not associated with the root node of the UI XML document. Thus, the XBind for this variant contains a base path that references the node corresponding to the view logic. The choice for this example XBind is "null" which does not contain data. If the expression is evaluated, the execute method 1200 proceeds to block 1206 and is described below.

Referring now to FIG. 12B, the exchange that occurs when an expression is evaluated is described. The description of FIG. 12B includes a set of objects including instance object 1250, process object 1252, and view object 1254. Similar to the description provided with reference to FIG. 10C, the dashed arrows shown in FIG. 12B indicate that the process and view objects 1252-1254 were previously associated with a localized relationship hierarchy specific to the instance object 1250. Indicates. Within the execute method 1200, the process object 1252 can use the instance object 1250 to evaluate the expression encountered. Since the instance object 1250 is provided when execution of the process step begins, the process object 1252 can use the instance object 1250 within the process step to cause the expression to be evaluated by the expression engine 1260. .

In one embodiment, the present invention implements an expression engine 1260 configured to evaluate expressions within the context provided by the instance. In particular, the functionality encapsulated in the expression engine 1260 may be used in the context of the instance object 1250 to evaluate the expression 1262 as XBind 1264, XML format data, or plain text. Once evaluated, the XBind 1264 identified by the expression engine 1260 is passed from the instance object 1250 to the process object 1252. By using the instance object 1250 to instantiate and accommodate the local expression engine 1260, the evaluation of expressions is easily performed with respect to the context provided by the instance or sub-instance. First of all, using the local expression engine 1260 in this way allows instance and scope handling to be performed within multiple changed scope depths. Thus, expressions can be evaluated differently, depending on the application instance running, and developers need not account for the complexity of managing multiple instances or scopes. Further descriptions of the functions implemented within the expression engine 1260 and the types of expressions that can be evaluated by the present invention are described in detail below. In this regard, the expression engine 1260 can be used to evaluate multiple expressions defined within a task. Each expression in the job is evaluated before the job handler is called and is described in detail below.

Referring back to FIG. 12A, the execute method 1200 begins execution of the appropriate job handler at block 1206. As mentioned above, a plurality of job handlers are provided by the present invention. Each task handler implements functionality specific to the kind of task it encounters. Thus, if the current job is an open job, the execute method 1200 calls the open job handler at block 1206. However, other task handlers (Bind, Decision, Action, Change, etc.) are implemented to be called within the execute method 1200. Thus, the execute method 1200 is set up to pass the appropriate arguments to the particular task handler invoked using well defined process task APIs, which are described in the examples below. However, each job handler is provided with an XBind that is evaluated at least with instance and process objects when it is called.

In decision block 1208, the execute method 1200 determines whether further tasks in the process step are to be executed. Thus, if all tasks in the current process step have not been executed before, the execute method 1200 returns to block 1202 and blocks 1202-1208 are repeated until each task is executed. In particular, the process step may include a statement indicating the flow of application execution. For example, a "call" statement can be defined as a statement in a process step that directs the flow of execution to another process job when all the jobs in the current process step are executed. More generally, a "call" task is provided in which developers direct the flow of execution between the actions of one process step and the other process steps. Once the "call" job is defined, the flow proceeds to a new process step and upon completion returns to a position within the started process step. In a practical embodiment, asynchronous calls, time delay calls and time repeat interval calls may be generated using the "call" operation. Thereafter, when all the work is executed, the execution method 1200 proceeds to block 1210 where it terminates.

As discussed above, the execute method 1200 initiates execution of specific task handlers when interpreting application logic. With continued reference to the MyTasks application described above, the functionality implemented by specific task handlers is described. Because the job handler implements a state change, all the data the job handler uses is provided. In addition, aspects of the present invention are set such that task handlers do not return data. Thus, task handlers can be implemented as standalone functions that are supplied with everything used to execute without returning data. Thus, process tasks of the application can be executed locally. However, task handlers are independent functions, so they can be provided as web services from a server-side data center.

Referring now to FIG. 13, an example open handler routine 1300 using an open task handler is described. In the example MyTasks application (FIG. 12A) described above, the application defines an Open task 612 with attributes that are evaluated for XBind within the execute method 1200 (FIG. 12A). Thus, the open task handler can be called to execute the open task 612. In one embodiment, the arguments may be passed to the open task handler upon invocation of an open task handler that includes previously evaluated XBind and appropriate instance and process objects.

As illustrated in FIG. 13, at block 1302, the data type recognizer is invoked within an open task handler for opening a document. As mentioned above, a previously evaluated XBind may point to a document or piece (node) within the document being opened. First of all, the open task handler passes a previously evaluated XBind that identifies the document being opened when invoking the data type identifier. Upon receiving the call, the data type recognizer performs processing at block 1304 to identify the file type of the document referenced in the received XBind. In the example MyTasks application described above, the XBind passed as the data type identifier refers to a document named "MyTasks_gui.xml". In this example, the data type recognizer identifies the file type that will be the UI XML document. As discussed above, logic is provided within the data type identifier that associates operations with a particular file type. One set of example operations initiated when a data type recognizer is used to open a UI XML document is described below.

At block 1306 of open handing routine 1300, the data type recognizer passes a command to view manager 908 indicating that a request to open a UI XML document has been received. In particular, the view manager 908 is called to create view objects that can be used to render new user interfaces or application views. As mentioned above, the user interface of the application is semantically described in the UI XML document (eg, "MyTasks_gui.xml"). In this regard, multiple view objects may be associated with each application instance. Thus, upon a call to the view manager 908, the identifier of the UI XML document describing the appropriate instance and the new view may be provided by the data type recognizer.

As described in FIG. 13, at block 1308 execution of logic begins to provide a semantic description of the new application view. As discussed above, the view manager 908 is responsible for instantiating the view object and performing the task of rendering the application view described in the UI XML document. To render a new application view, component and dialog objects are instantiated using the view object. As described in detail below with reference to FIG. 23, these objects provided by the present invention implement the functionality to cause graphical elements semantically described in a UI XML document to be rendered on a computer display. The open handling routine 1300 then proceeds to block 1310, where it terminates.

Referring now to FIGS. 14A-14B, the use of data type recognizers and UI XML documents in the opening process is described in further detail. The description of FIG. 14A illustrates a process object 1400, an open task handler 1402, a data type identifier 1404, an instance object 1406, a view manager 908, and a view that interact when the UI XML document is opened. An object 1408 is shown. Thus, the block diagram of FIG. 14A may correspond to objects used by the open task handling routine 1300 described above with reference to FIG. 13. Opening of the application view may be initiated by process object 1400, which invokes open task handler 1402 to open the particular document identified by the evaluated XBind. Upon receiving the call, open task handler 1402 uses data type recognizer 1404 to identify the file type and allows appropriate actions to be executed. In one embodiment, when a UI XML document is passed from the open task handler 1402 to the data type recognizer 1404, actions are defined that open the application's view logic and start execution. In addition, data type recognizer 1404 is used to associate the result view object 1408 with the appropriate instance object 1406.

In the example shown in FIG. 14A, view manager 908 is called by data type recognizer 1404 when a call is received to open a UI XML document. To open and execute the logic of the UI XML document, the view manager 908 instantiates and supplies a view object 1408, an identifier of the instance object 1406, and an XBind that references the appropriate UI XML document. By passing the data this way, the view object 1408 becomes aware of the instance associated with it. Once the view object 1408 is instantiated, execution of logic to provide a semantic description of the new application view begins with functionality similar to the process start routine 1100 (FIG. 11) described above. In particular, the view manager 908 can cause the appropriate UI XML to be loaded into the client side cache. The view object 1408 can then be instantiated and used to render the user interface components and dialogs of the application. However, unlike processes, multi-view objects can be associated with the same instance if they can be instantiated.

In a practical embodiment, aspects of the present invention support lazy loading and / or rendering of the UI logic of an application. To this end, XLinks implemented in accordance with the standards defined by the World Wide Web Consortium can be used to perform lazy loading and / or rendering of one or more UI XML documents. Those skilled in the art can appreciate that XLink can be included in an XML document that describes a link between different XML resources. Unlike traditional HTML-based hyperlinks that provide users with the meaning of linking web pages, XLinks are more easily interpreted by software systems and computers. In particular, XLinks may include logic to define the conditions under which to activate XLinks as well as the actions to be taken upon activation. As a result, XLinks are best suited for performing on demand and / or lazy rendering of application UI logic. Instead of loading all of the application's UI logic when the application runs, XLinks can be defined to link with the appropriate XML resources required. For example, in the example MyTasks application described above, the Button2 component 704 is "hidden" after the user interface logic of all the applications are loaded and rendered. Even functionality and improved performance can be achieved by using XLinks to load and / or render the UI logic of the Button2 component 704 as needed. In this example, the user interface logic of the Button2 component 704 of the MyTasks_gui.xml document 650 will contain XLinks that reference local or remote resources (eg, other UI XML documents) that have defined associated user interface logic. Can be. If instructed by the application logic, these XLinks can be used to load and / or render the UI logic corresponding to the Button2 component 704.

When the open task handler 1402 is complete, the result view object 1408 is returned to the data type recognizer 1404. The data type recognizer 1404 then associates the view object 1408 with the appropriate instance. In particular, when a new application view is created, the data type recognizer 1404 passes the resulting view object 1408 to the instance object 1406. In response, MiniView Manager 1412 is updated to associate the view object 1408 with the corresponding instance. More complex names are assigned to view objects 1408 in view manager 908 than are assigned to the same objects by MiniView manager 1412. In particular, the name assigned to the view object 1408 in the view manager 908 includes the identifier of the corresponding instance object 1406. As described in detail below, by implementing a system for naming objects in this manner, the same view can be distinguished among multiple application instances. By controlling the passing of data in this way, aspects of the present invention implement a localized relationship hierarchy that delimits application instances.

Referring now to FIG. 14B, the use of the data type identifier 1404 when opening a process XML document is described in further detail. Similar to FIG. 14A, the description of FIG. 14B shows the process object 1400, the data type recognizer 1404, and the instance object 1406 as well as the process manager 906. Thus, the block diagram shown in FIG. 14B may correspond to the objects used by the process start routine 1100 (FIG. 11). When the process XML document is opened, a data type identifier 1404 is used in the context of the application package or in a standalone application to identify the file type of the document. In this example, data type recognizer 1404 defines the operations that enable the opening of the logic and the execution of the logic described in the process XML document. In particular, the flow of execution proceeds from data type recognizer 1404 to process manager 906 instantiating process object 1400. When the process XML document is opened, a reference to the resulting process object 1400 may be returned to the data type recognizer 1404. The data type recognizer 1400 then provides an instance object 1406 with a reference to the resulting process object 1400. In response, MiniProcess Manager 1414 is updated to associate process object 1400 with the corresponding instance.

15A-B, an operational task is described that provides an example of the use of the MiniView Manager when enabling process execution. When the Open task 612 of the MyTasks application is executed, the flow of execution proceeds to the Action task 614 (FIG. 6A). In this regard, the operation handling routine 1500 is described with reference to FIGS. 15A-B describing logic as well as interactions between the objects involved in implementing the routine 1500.

As described in FIG. 15A, the expression represented by the value attribute of the Action task 614 is evaluated to XBind at block 1502. In the example MyTasks application, the Action task 614 includes a value attribute "# MyTasks " which is evaluated with XBind in block 1502. With particular reference to FIG. 15B, the functionality encapsulated in the expression engine 1550 may be used by the instance object 1552 to evaluate the “#MyTasks” expression into the XBind. In this example, the expression engine 1550 is set to perform a lookup in the MiniView Manager 1554 for the view object named "MyTasks". When a new application view is created, the resulting view object is passed to the corresponding instance that updates MiniView Manager 1554 accordingly. In this regard, the MyTasks view object is assigned a simple name within the MiniView Manager 1554 accepted by the instance rather than the more complex identifier used for the views of the global view manager 908. Complex names are used to distinguish views that belong to different instances and applications, so more complex names are not necessary for instance instances. Since the MiniView Manager 1554 houses its own views, this information is already known to the instance and the MiniView Manager 1554. By providing this architecture, the expression engine 1550 can distinguish between views associated with different instances and applications with the help of the MiniView Manager 1554. Therefore, in the exemplary MyTasks application, MiniView Manager 1554 includes a view object named "MyTasks". The view object also contains a reference to the instance with which this view object is associated. When evaluating the "#MyTasks" expression, the expression engine 1550 identifies the MyTasks view object 1558 as a "emitter" of the source or task. In particular, MyTasks view object 1558 associated with instance object 1552 is identified as an emitter and is not a "MyTasks" view object associated with another instance. Since the expression engine 1550 evaluates the expressions on the instance, the exact MyTasks view object 1558 that was the source of the event is identified using the MiniView manager 1554.

In this example, the XBind returned to the process object 1556 includes a URL that references the MyTasks_gui.xml document 650 and the MyTasks view object 1558. An indicator is included with XBind, which is the emitter or source of the task on which the MyTasks view object 1558 is running. If the lookup of the MiniView Manager 1554 does not identify a match for the object referenced in the expression, the expression engine 1550 is set to perform the lookup in the view manager 908 to obtain the associated view object.

At block 1504 of the routine 1500, the process object 1556 begins execution of the action task handler 1560. In the example MyTasks application, an XBind previously evaluated using the expression engine 1550 and the emitting MyTasks view object 1558 is passed to the operational task handler 1560 by the process object 1556. Thereafter, at block 1506, the action task handler 1560 causes the method to be performed, as specified in the application process logic. In this example, the action task 614 of the MyTasks application defines the following "<component>" XML element that identifies the method and the target on which the action is to be performed.

<component name = "button2" action = "hide" value = "" x / component>

By defining this element, the application code instructs the component named "button2" to be hidden. In one aspect, view objects are encoded with generic methods that perform state operations on associated user interface components, including but not limited to enable, disable, hide, show methods, and the like. . Since the MyTasks view object 1558 is passed to the action task handler 1560, these generic methods can be called directly on the object 1558. In this example, the action task handler invokes the "hide" method on the MyTasks view object 1558 and identifies the Button2 component 1562 as the target component to be hidden. The action handling rujin 1500 then proceeds to block 1508, where it terminates.

Referring now to FIG. 16, the implementation of the bind task handler is described in further detail. Once the Open and Action tasks 612-614 of the MyTasks application are executed, the flow of execution proceeds to a bind task 616 (FIG. 6A). As illustrated in FIG. 16, at block 1602, the expression represented in the value attribute of the Bind operation 616 is evaluated to XBind and returned to the appropriate process object. Similar to the description above, the process object uses an expression engine local to the instance that evaluates the provided expression. In the example Bind task 616, the "data / tasks.xml" expression is evaluated to the next XBind at block 1602.

URL = data / tasks.xml

Base path = /

Selection =

The URL of the XBind refers to a data document that stores task descriptions. The base path also refers to the root node of the data document corresponding to the URL, and the optional aspect of this exemplary XBind is null.

At block 1604 of the bind handling routine 1600, the process object being used to execute the current process step begins execution of the bind job handler. On call, the bind job handler receives the previously evaluated XBind and the appropriate process and instance objects. As mentioned above, developers can create a task in accordance with process task APIs that define XML semantic structures and function call parameters that may exist within the body of the task. In this example, the Bind operation 616 (FIG. 6A) defines the following "<component>" XML element 618.

<component view = "MyTasks" name = "input3" select = "/ tasks / task / @ description">

Thus, the bind task handler (called at block 1604) is responsible for interpreting this logic to bind a particular component to a fragment in an XML document. More generally, each task handler is responsible for interpreting the logic defined in the child elements of the work element. In this regard, process task APIs allow developers to define XML syntax in the body of a task to ensure that the logic executed within the task handler is set as needed.

At block 1605, the view object corresponding to the component bound to the underlying XML document is identified and returned to the bind task handler. In this example, the component element 618 interpreted by the bind task handler identifies the "Input3" component as being created in the context of the "MyTasks" view object. Since the appropriate instance object is provided to the bind task handler, the correct view object can be easily identified. In particular, a lookup in the instance's MiniView manager is performed, and the "MyTasks" view object is returned directly to the bind task handler.

As illustrated in FIG. 16, the translated XBind is generated in the bind task handler at block 1606. The XBind passed to the bind task handler stores the content used by the MyTasks application. However, only a subset of the data of the identified XML document is bound to the Input3 component. Thus, the binding performed by bind task 616 in this example is set to narrow the binding of the Input3 component to the pieces of data in the "data / tasks.xml" document identified by the XPath expression. In particular, the selection characteristic of component element 618 includes an XPath expression that qualifies the expression in the value attribute of bind operation 616. In this example, the XPath expression identifies the appropriate fragment in the XML document that is used to bind the incoming handler and make the incoming XBind fit to produce the next translated XBind.

URL = data / tasks.xml

Base path = / tasks / task / @ description

Selection =

The above-described translated XBind may be abbreviated as data/tasks.xml#/tasks/task/@description. In this regard, the translated XBind's URL refers to an XML document in a data model that stores related descriptions. Within the XML document identified by the URL, the base path refers to the task element and its associated description attribute. As described in detail below, the XBind may include a "Selection" which provides an additional feature in referencing fragments in the data model.

At block 1608 of the bind handling routine 1600, the setup data function provided by the appropriate user interface component is called. In this example, the Input3 component is the subject of a Bind task 616 and is bound to a list of task descriptions. Component APIs can be used to define certain methods for setting data in a particular component. In one embodiment, the Input3 component may include a configuration data method that is called at block 1608. In particular, suitable components may be identified based on a reference to the component name received at block 1604 when the view object and bind task handler are invoked.

 When called, the configuration data method performs management functions and error handling to ensure that the component is not already bound to an XML document in the data model. Then at block 1612, the Input3 component that is the target of bind task 616 is added to the "data / tasks.xml" document as an update listener. As mentioned above, the present invention provides a structured object-oriented representation of an XML document in the form of a document object. In one embodiment, document objects serve as wrappers for DOM ("Document Object Model") objects used by web browsers and XML parsers. In this regard, the improved features are encoded in the document object provided by the present invention, including the ability to add any objects present in the network operating system environment as listeners for updates applied to the data model. By way of example only, objects that may be data update listeners include, but are not limited to, processes, views, components, communication channels, and the like. At block 1612, it is called to add the Input3 component as an update listener to the object corresponding to the "data / tasks.xml" document. In this regard, each document object maintains a list of listeners to be notified in response to data updates. By issuing a call to add update listeners at block 1612, the Input3 component becomes one of potentially many data listeners on the same document object.

At decision block 1614, a determination is made as to whether the component added to the document as an update listener uses the rules. In one aspect, the present invention supports functionality that allows rules to be associated with a data binding component. In this regard, rule handlers may be included in the data model that define whether components and other objects interpret their data binding. As described in detail below, the rules allow generic components to interpret, learn, and take appropriate action based on the content of the data model. Thus, XML semantics or languages with different elements, attributes and hierarchies can be understood and / or bound to the same kind of generic components. In other words, components that use rules do not need to be created specific to any data model. Instead, rules allow a generic set of components to be used with any kind of underlying data, thus enabling true data abstraction in the MVC design paradigm. The component does not need to understand the structure of the underlying data model, and may use rules to interpret the content to achieve the desired functionality. When setting up bindings with components that use rules, functionality is implemented to set up and update rule handlers so that rules can be applied. In a call to add a component as an update listener, a flag may be included indicating whether the component is a rule user. Thus, if the received flag indicates that the component is not a rule user, then the result of the test performed at block 1614 is "no" and the bind handling routine 1600 proceeds to block 1618 and is described in detail below. Conversely, if the flag received indicates that the component is a rule user, then the result of the test is "yes" and the bind handling routine proceeds to block 1616. At block 1616, a set rule routine 1600 is executed that applies or merges the rules of the data binding component to the rule handler maintained in the data model. In this regard, the logic implemented by the setup rule routine is described in detail below with reference to FIG.

At block 1618 of the bind handling routine 1600, a call is made to update the user interface of the component that is the subject of the bind operation. Methods defined according to component APIs can be used to perform updates of the user interface. In particular, component APIs allow developers to provide the logic used to implement "Update ()" methods for a component. In this regard, the logic that may be implemented within the "Update ()" method is described in detail below with reference to FIG. In this example, the "Update ()" method associated with the Input3 component results in task descriptions maintained in the data model being displayed. The bind handling routine 1600 then proceeds to block 1620, where it terminates. Once the bind task 616 completes execution, the new data binding component is notified of updates affecting the data model ("data / tasks.xml").

In the example MyTasks application (FIG. 6A), the Bind task 616 is the last task in the Initialize Application process step 604 that is executed. When the bind task 616 is executed, processing of the MyTasks application remains idle until a trigger is created. In this regard, the trigger activation routine 1700 is described below with reference to FIG. 17. However, prior to describing the use of triggers, a description of the functionality implemented by the expression engine provided by the present invention is described in further detail.

On existing platforms, developers are provided with the same programming tools that query data and define the computational logic of the application. In this regard, in fact the imperative programming language allows the logic of every application to be eventually represented as a series of ordered declarations. The ordered nature of stringent programming tools makes them suitable for implementing computational logic, while the strict language's ability to query data becomes less robust. Instead, non-imperative language programming tools are suitable for querying or accessing data. To this end, when performing VOs, expression languages are provided that allow developers to use non-instructional programming language tools. In this regard, expressions are structured to be compatible with XML syntax and are limited within the XML-based programming languages provided by the present invention. Specific examples of how process XML language can easily use expressions are provided herein. However, the expressions should be construed as illustrative, as expressions may be combined for use in other XML languages and may also be evaluated and used directly from program code within the objects.

Implementation of a development platform set to run applications that adhere to the MVC design paradigm presents challenges with access to data that may change at runtime. In one embodiment, XBind provides a standardized means of referring to in-memory objects, documents, data subsets, and the like. As mentioned above, XBind is a three-dimensional data that includes a URL, a base path (e.g., an XPath expression that references a fragment or entire XML document in an XML document), and a selection (e.g., a plurality of XPath expressions). It's kind. Thus, XBind allows different parts of a loosely coupled system to efficiently send and receive their status information in a standardized way. In this regard, XBinds provide a simple and easy way to bind data to user interface components. Through the use of selections, the state of the component can be described in XBind, which can be provided as input to other systems. More generally, each object in the network operating system environment can always be queried for an XBind that describes the state of the object. Thus, an XBind that describes the state of an object can be set to another object to "duplicate" or convey the state of the components. In another aspect, XBinds associated with an object may be synchronized over the network. As a result, objects running on remote computers can be updated using XBind to stay synchronized. This is one way that aspects of the present invention enable real-time collaboration over a network.

In one embodiment, XPath valuations may be applied by the expression engine. Those skilled in the art will appreciate that XPath is a standard in the World Wide Web Consortium (W3C) that provides a language for identifying and selecting data in XML documents at specific locations. XPath also sets conventions that produce expressions that evaluate specific values. For example, an XPath expression "/ tasks / task / @ description" containing an abbreviated syntax of the "@" symbol looking for an attribute named "description" is used in the MyTasks application. This syntax conforms to XPath conventions and is used to refer to a subset of data in an XML document that meets certain selection or matching parameters.

The expression language provided by the present invention allows developers to reference in-memory objects that may experience state changes at runtime. For example, the "#MyTasks" and "# MyTask # input3" expressions refer to different view and component objects, respectively. Using a simple notation, developers can distinguish between these internal memory objects and their data bindings. For example, if a developer accesses data bound to a "Input3" component instead of referring to an object, the "{# MyTasks # input3}" expression can be used. This particular expression evaluates to the value found in the XML document referenced in the XBind associated with Input3 in the MyTasks view. When encountering an expression containing curved parentheses ({or}), the expression engine converts one or more XML nodes bound to the identified object into text or XML. In this regard, the view and component objects provided by the present invention are aware of their data bindings and can always be queried for their XBind. By evaluating the expressions on the instance, the expression engine can identify the appropriate object and the corresponding data binding when evaluating these kinds of expressions. Thus, Expression Language allows developers to refer to internal memory objects and their data bindings using the same simple notation. Expressions may also refer to external resources identified by a URL that can be obtained automatically using a communication channel.

Unlike existing systems that use XPath for navigation and selection of data within documents, aspects of the present invention allow internal memory objects and their associated data to be referenced using XPath conventions. Assuming a component named "Input1" exists in an application view called "MyView", the following are valid expressions that are evaluated by the present invention.

{#My View # input 1 # @ name}

 After a reference to an XML document, variable, or internal memory object, XPath conventions are applied after the last "#" character in the expression for the components XBind. Upon encountering a relative XPath expression, the selection within the base path or component is merged with the provided XPath described with reference to bind handling routine 1600 (FIG. 16). In the example expression provided above, the last "#" indicates that the XPath expression (eg "@name") is relative so that this XPath expression is merged with the XBind of the components. However, XPath expressions evaluated by the present invention may also be absolute. In evaluating an absolute XPath expression denoted by "/", aspects of the present invention ignore the base path or selection of the XBind of the components. Aspects of the present invention utilize XPath conventions in a manner different from that described above. Further examples of the use of XPath treaties, in addition to other kinds of expressions that may be evaluated by the present invention, are commonly assigned US Provisional Patent Application 60 / 976,339, "Network-Based Operating System" (September 28, 2007). One application), the contents of which are hereby expressly incorporated by reference.

In one embodiment, the properties of the internal memory object may be connected using an expression language. These properties can be accessed regardless of their data type according to the following syntax.

# MyView.id

Methods that perform operations on internal memory objects may be called using an expression language. In this regard, the internal memory objects provided by the present invention can be encoded with these methods. Using expression languages, methods can be called directly on these objects. For example, the following are the types of expressions evaluated by the present invention that invoke a method on an object.

# MyView # maximize ()

# MyView # input1.clear ()

Also, higher-order expressions that accept other expressions as arguments are valued by the present invention. In other words, the expression language supports repetitive evaluation of expressions that conform to non-instructional programming techniques, as the following example illustrates.

# MyView # {# MyView # inputl.getName ()}

In this example, the name of the Input1 component is first evaluated in the internal expression using the getName () method. The repeatedly evaluated expression that identifies the component name is provided as a parameter of the external expression. This is an example of how non-instructional programming tools are combined and used with the XML programming languages provided by the present invention.

Within a network operating system environment, tasks associated with process steps may be executed in response to the generation of a trigger. In other words, the execution of the process steps may be event driven. Thus, once the MyTasks.xml document 600 is opened, the trigger 602 can be registered so that the flow can be directed to the appropriate process step when the trigger is activated. Trigger activation routine 1700 is described with reference to FIGS. 17A-B, which illustrate flows and interactions between objects used to implement routine 1700. As mentioned above, the MyTasks.xml document 600 defines the following trigger 602.

<trigger view = "MyTasks" component = "button 1" event = "select" step = "2">

The trigger activation routine 1700 shown in FIG. 17 assumes that the user activates the trigger 602 at block 1702 by selecting the Button1 component identified within this trigger element.

In response to the activated trigger, the component object on which the trigger occurred passes a notify listeners call to the event manager 914 at block 1704. Upon invocation, the appropriate component object provides a set of event data and instructs the event manager 914 to notify all event listeners that have registered a notifier object or an object that matches the provided data. With particular reference to FIG. 17B, the Button1 component object 1750 associated with the MyTasks view object 1750 passes a notification listeners call from the block 1704 to the event manager 914. Upon invocation, an expression (eg "# MyTasks # button1") is provided that identifies the component from which the trigger event originated, as well as the event type (eg "select").

At block 1706, the event manager 914 notifies one or more listening objects about the activation of the event. In particular, the event manager 914 performs a lookup whether the event data passed from the Button1 component object 1750 matches the data provided when the event listener was previously registered. In this regard, process start routine 1100 (FIG. 11) provides a description of whether objects can register event listeners with event manager 914. In one embodiment, each trigger encountered in the process XML document causes the corresponding Notifier object to be temporarily stored in memory as an event listener in advance when the application is first started. The Notifier object is temporarily stored in memory at first startup of the application in anticipation of one or more application instances activating the trigger. The pre-stored notifier object is associated with the view name, component name, and event type, which serve as a unique key when performing the lookup at block 1706. In other words, the corresponding notifier object is notified of the event activation only when the component experiences the kind of event identified in the trigger within a particular view. Thus, only a single notifier object registers with the event manager 914 for a trigger defined in the process XML document, regardless of the number of running application instances. Even if there are multiple instances of the application, this architecture allows the same Notifier object to be reused by each application instance. Additionally, this architecture allows the event manager 914 to iterate more efficiently and notify listeners because a single trigger registers the event listener in the form of a Notifier object that is then shared by multiple application instances. In other words, the performance of the lookup performed at block 914 is not dependent on the number of running application instances.

 At block 1708 of the trigger activation routine 1700, a suitable instance associated with the activated event (trigger) is identified. Upon being notified of the occurrence of the event, the arguments are passed to the event manager 914 which is used to identify the appropriate listening object and the affected instance. In this example, an expression identifying Button1 component object 1750 is provided to event manager 914 and can be used to identify the appropriate instance via a connection to a component view object that accepts a reference to the instance to which it belongs. As mentioned above, when opening an application view, a reference to the instance is provided to the resulting view object. Thus, the MyTasks view object 1754 recognizes the instance object 1758 associated with it. Since the component objects are created within the context of the view, the Button1 component object 1750 can use the MyTasks view object 1754 to identify a suitable instance at block 1708. Once a suitable instance is known, instance object 1758 is provided to the execute method of the process object.

The architecture and description shown in FIG. 17B above describe how the present invention supports the execution of process steps that are not state preserved in a system that supports event driven execution of application logic. As mentioned above, a single process XML document is used to execute multiple application instances. In this regard, process objects can be reused repeatedly by other application instances, thus providing an efficient platform for running applications. Although only a single notifier object 1756 is temporarily stored for each kriger in the application in advance, the present invention may allow a suitable instance to be provided to the process object 1700. In this regard, the notifier object 1756 is activated when an event matching the unique key including the view, component, and event type is received by the event manager 914. In addition, the event manager 914 may use the provided component, view or event listening object to identify the appropriate instance object 1758 and provide it to the notifier object 1758. At block 1712 of the trigger activation routine 1700, a call is made to execute a process step in the application. As mentioned above, the process steps to be executed are temporarily stored in the notifier object 1756 or known by the event listening object. Thus, if a suitable instance is provided, the notifier object 1756, at block 1712, comprises (1) an instance object 1758 representing the current runtime state of the application and (2) a process step in the process logic of the application to be executed ( For example, you can call the execute method (FIG. 12) that provides "2". The trigger activation routine 1700 then proceeds to block 1714, where it terminates. Other event listening objects can call process object steps or execute their own custom code.

 When the trigger of the MyTasks application is activated, the execution flow proceeds to decision task 620. Generally speaking, the logic in decision task 620 performs a test to determine what text has been entered into the Input4 component when the trigger 602 is activated. In this regard, a decision handling routine 1800 that implements decision task 620 is described with reference to FIG. 18. As illustrated in FIG. 18, decision handling routine 1800 begins at block 1802 where the expression is passed to the expression engine for evaluation. In this example, decision task 620 includes a value attribute "# MyTasks # input4" that is passed to the expression engine for decision at block 1802. As mentioned above, developers can use the expression language provided by the present invention to refer to internal memory objects. In particular, the "# MyTask # input4" expression, selected at block 1802 and passed to the expression engine for evaluation, references a component object that may experience a state change when the application is executed.

 In block 1804, it is determined whether to refer to a component associated with a data binding that is an expression being evaluated. In some cases, data binding may define whether data input and / or data displayed by the component is automatically propagated between the component and the data model. On the other hand, a component may not be associated with "atomic" or existing data binding. When evaluating expressions that reference atomic components, the expression engine implements functionality that allows data input / output from the component or other data that affects the state of the components to be accessed within the logic of the task handler. By implementing this functionality, the expression engine ensures that this data is always accessible using XML-based expressions.

To determine whether a component is associated with data binding at block 1804, the expression engine may use a instance to identify a component object named "Input4". As mentioned above, the component objects provided by the present invention recognize their data bindings. Thus, once a suitable component object is identified, the expression engine can easily determine whether the component is atomic or associated with data binding. If the result of the test performed indicates that the component referenced in the expression is not associated with the data binding, then the decision handling routine 1800 proceeds to block 1808 and is described in detail below. Conversely, if the result of the test performed at block 1804 indicates that the expression references a component associated with data binding, the decision handling routine 1800 proceeds to block 1806.

Upon reaching block 1806, the component referenced in the encountered expression is associated with a data binding. In this example, the expression is evaluated without generating a temporary XBind that describes the nonexistence of the data binding. More specifically, the express engine evaluates the "# MyTasks # input4" expression at block 1806 and requests an XBind from the Input4 component. In this example, the XBind returned by the expression engine provides everything the job handler needs to run.

In one embodiment, developers may provide XML semantic descriptions to access data or perform I / O. However, expressions may require data available only from internal memory objects implemented in scripting languages (eg, Java Script). Thus, even if a component is not associated with a bind, the present invention allows expressions to compute and access data associated with the component using the corresponding internal memory object. For example, the decision task 620 of the MyTasks application includes the following "<when>" XML element 622.

<when test = "text () =" "step =" 37>

<otherwise step = "4" />

 when element 622 includes an XPath expression "text ()" that applies XPath validation conventions to request that text be input to an Input4 component. Because the component is atomic, the requested data cannot use existing data bindings. Instead, the present invention evaluates XML-based expressions and allows access to data even if the requested data is not currently maintained in the data model. Instead, a temporary XBind is created for an object (eg, a component) that references a fragment in a system-provided state document. As described in detail below, a system-provided state XML document may include all state information of related components.

In the blow 1808 of the decision handling routine 1800, the requested data is obtained from an internal memory object associated with the atomic component. Logic implemented within a task handler may use data that includes the state of the atomic component. For example, upon reaching block 1808 of decision handling routine 1800, the Input4 component is an atomic component that is not associated with data binding. Thus, the XPath expression "text ()" in the body of decision operation 620 requests data that includes the state of the component that is not bound to a known document in the data model. In order to properly evaluate this kind of expression, the requested data must be available from the data model. In this regard, since there is no XBind requested in the expression, the expression engine may query the Input4 component for related data.

In one embodiment, each time an atomic component is referenced in an evaluating expression, the system-provided state XML document is updated with the current state of the component. As will be described in detail below, a temporary XBind can then be generated that points to a suitable fragment within a system-provided state XML document from which the requested data can be obtained. In another embodiment, the state of all components of the system (regardless of whether the components are related to atomic or data binding) may be continuously propagated to the system-provided state XML document using functionality encapsulated in the State Manger. In this example, the requested data is always available from the data model and accessible using a translated XBind, as described below. In particular, this embodiment enables synchronization of the state of the application across multiple client computers. Also, by automatically propagating state information to the data model in this way, the state of the application can be easily recovered when the application is closed and subsequently opened.

At block 1810, a temporary XBind is created for connecting to data obtained from the atomic component and returned to the appropriate process object. If the application includes a task that uses an atomic component, the data may be obtained from a component object and stored in a memory provisioned state document. A translated XBind is created that is used temporarily to evaluate this expression, which references the location in the state document from which the requested data was obtained. When evaluating the "# MyTask # input4" expression, the expression engine can generate an XBind similar to the following:

URL = #State

Base path = / states / state [@qid = '# MyTasks # input4'] Selection =

   The URL of this XBind refers to a system-provided state XML document assigned to store component state information. The base path also indicates the node in the state document in which text entered into the Input4 component in block 1808 is stored. Once evaluated, the temporary XBind is returned to the appropriate process object from the expression engine. By storing state information and creating a temporary XBind in this way, aspects of the present invention allow developers to use XML-based expressions to refer to components and their data, regardless of whether the component is involved in data binding. More generally, all job handlers that access XML documents can work with and reference atomic objects that are not involved in data binding. As in the example described above, references to objects (eg components) of the expression are evaluated in XBind. As a result, aspects of the present invention allow components to bind to each other. If this kind of binding is defined, the second component effectively "replicates" the XBind of the first component. In other words, the second component is provided with a synchronized XBind from the first component. Data binding between components is possible even if the target of the binding is an atomic component. In this case, the second component is associated with an XBind that references a time-provided document describing the state of the first component. Since the first component is atomic, this effectively creates a master-slave relationship between the two components.

As detailed in FIG. 18, the decision task handler is called at block 1812 to perform the evaluation defined at decision task 606. In this regard, the parameters are passed to the decision task handler, which may include a temporary XBind upon invocation, if the task includes an atomic component. In one embodiment, developers can create tasks in accordance with a task API that defines function call parameters and an XML semantic structure that can exist within the body of the task. At decision 620, elements are defined that direct the program execution flow according to the result of the evaluated XPath expression. In this example, a string comparison is performed within the decision task handler to determine if text has been entered into the Input4 component. Thus, the XPath expression (eg "text ()") is evaluated as text in the decision task handler. In the case where an expression being evaluated references data from an atomic component, a translated temporary XBind is used to obtain the requested data to evaluate the particular expression. In particular, the XBind passed to the decision task handler may include a reference to a system-provided state document to which state data previously abstracted from the Input4 component is accessible.

Then, at block 1814, a call is made to perform the appropriate process step of the application. The result of the evaluation performed within the decision task handler determines whether to direct the flow of execution to process step 608 or process step 610. When the decision task handler is invoked, the XBind is received as well as the process and instance objects. These received arguments allow the decision task handler to easily begin the execution of the next appropriate process step depending on the result of the evaluation. In this regard, the received arguments may be modified or passed directly by the decision task handler. The decision handling routine 1800 then proceeds to block 1816, where it terminates.

As described above, the decision operation 620 causes the execution flow to proceed to the process step 610 if no text is input to the Input4 component upon the occurrence of the trigger 602. The only task in process step 610 is an operational task 628 for the button component to display. In this regard, the action task 628 may be executed using the action task handler described above with reference to FIGS. 15A-B. Thus, further description of the functionality implemented when the program flow is directed to process step 610 is not described in detail herein.

If text is input to the Input4 component upon the occurrence of the trigger 602, execution of the MyTaks application proceeds to process step 608. The task defined within process step 608 is a change task 624 that causes text entered into the component to be added to the XML document. In this regard, an example change handling routine 1900 that implements data update using a change task handler is described with reference to FIG. 19.

As described in the description of FIG. 19, the change handling routine 1900 begins at block 1902 where expression evaluation is performed. In particular, the "data / tasks.xml" expression of the value attribute of change task 624 is evaluated to XBind at block 1902. In this example, the XBind generated from the valuation contains the base path and the URL referencing the root node of the "data / tasks.xml" document.

As explained above, the expression of the value attribute of a job is evaluated with an XBind for each of the jobs of the application. In one embodiment, expressions in the body of a task may be evaluated in logic implemented by an operator handler. In another embodiment, expressions in the body of a task may be evaluated before the appropriate task handler is called. While both embodiments are supported, it is desirable that the valuation of expressions in the body of the task of the logic of the task handler is more efficient. In this regard, the change operation 624 includes the following "<store>" XML element 626.

<store type = "append" select = "/ tasks / task / @ description" value =

"{# MyTasks # input4}"

The expression "{# MyTasks # input4}" in the storage element 626 is evaluated as text at block 1904. As mentioned above, the expression engine provided by the present invention allows developers to limit the valuation of expressions using curved parenthesis notation. These expressions can be defined in attributes, between elements, and at other locations in the application code. In this example, the logic in the expression engine causes the expression "{# MyTasks # input4}" to be evaluated as text.

In general, the modifications implemented by the present invention provide developers with a raw data manipulation tool for performing all necessary modifications to the content of an XML document. In this regard, a plurality of data manipulation primitives are provided that essentially conform to the World Wide Web Consortium's DOM standard. Aspects of the present invention also provide additional data manipulation primitives, including replaceText and delete children primitives. Accordingly, the following exemplary primitives provide the modifications provided by the present invention (replace, replaceText, append, prepend, insert, remove, It may be performed to change the contents of the XML document using remove children, new, and delete. Those skilled in the art can appreciate that the provided primitives can be used or combined to perform all necessary modifications to the data model. As described in detail below, any change that affects the data model causes a transaction to be created within the transaction manager 910 that describes the exact update to be made.

At block 1906 of change handling routine 1900, the change task handler is called by the appropriate process object. Upon reaching block 1906, the process object executing the current process can pass not only the appropriate instance and process objects, but also the previously evaluated XBind to the change task handler. As described in detail below, the change task handler uses the received arguments to modify the content of the XML document.

At decision block 1908 of the change handling routine 1900, it is determined whether the change operation being executed defines a data transform. The value attribute defined in change task 624 identifies the document that is the subject of the change task (eg, “data / tasks.xml”). Within storage element 626, the select attribute may include an XPath expression (eg, tasks / task / @ description) that references a location in a particular XML document in which data modification is to be performed. In addition, the select attribute may include an expression (eg, “{# MyTasks # input4}”) that evaluates the content to be pasted, replaced or included in the XML document. In one embodiment, aspects of the invention allow data to be modified within a change operation before being pasted, replaced, or added to the data model. For example, the storage element 626 may include transformation attributes that reference Extensible Stylesheet Language Transformation (XSLT) for performing specific data transformations. If this kind of data transformation is defined, the result of the test performed at block 1908 is "yes" and the routine 1900 proceeds to block 1910. However, change task 624 of the example MyTasks application does not include variant attributes. In this example, the result of the test performed at block 1908 is "no" and the routine 1900 proceeds to block 1910, which is described in detail below.

 At block 1910, data transformation is applied according to the logic defined within the change operation. In an actual embodiment, the storage element of the change action may include transformation attributes that reference the XSLT document. Logic in the XSLT document may be applied at block 1910 to transform the data from the source format to the destination format. Traditionally, XSLT has been used to transform data to support the dynamic creation and modification of web pages. XSLT is also used to transform between XML business format languages and their corresponding structures as part of Electronic Data Interchange (EDI) integrated servers. However, these examples are illustrative only and XSLT is used in other examples. Also, other transform languages may be used with the present invention and should not be construed as limiting the use of XSLT. In any case, those skilled in the art will define XSLT to define variations between XML schemas and other XML schemas or XML documents that implement a Document Type Definition (DTD), as well as between various markup languages (XML, HTML, XHTML, etc.). It will be understood that this is an XML-based language. In this regard, the XSLT processor may be used by the change task handler to apply data transformation at block 1910. By supporting dynamic applications of variants in this way, an improved development platform is provided that is well prepared for applications to exchange data, interact, and integrate / reuse functionality.

Computer users typically use multiple applications such as email, web browsers, calendar applications, word processors, media players, and the like. However, the data formats and logic used by different applications are not compatible using existing systems. For example, an e-mail program can allow users to define "contacts" used to store and access information related to other users. Meanwhile, the calendar application allows users to create meetings and appointments that include other users, groups, and the like. In response to reviewing a message from a contact defined in the email program, the user may want to automatically create a new meeting in the calendar application. However, supporting the functionality that allows different applications to interact in this way is not readily performed using existing systems.

The data transformation applied at block 1910 occurs before the raw data manipulation of the change operation is performed. By supporting dynamic applications of this kind of data modifications, aspects of the present invention provide application developers with better opportunities to affect the functionality and data available from other applications. In the example provided above, data modifications can be performed that easily allow email and calendar applications to interact. For example, an XSLT variant may be defined to convert received emails and / or contacts into data items describing new appointments. In this regard, the variant may utilize user input to set contact information, content of an email message, and / or attributes of a meeting. Within this change, even if different subschemas and XML structures are used, this kind of XSLT variant can be applied that allows different applications to communicate.

At block 1912 of the change handling routine 1900, a call is made to the appropriate URL object to perform the specific data update represented in the change operation. As described in detail below, the URL object provided by the present invention is a lightweight pointer that exposes methods for handling each of the different kinds of data modification primitives (described above) supported by the change operation handler. ) Plays a role. Thus, the change task handler uses the received XBind and logic within change operation 626 to identify the appropriate URL object to call. It is to be understood that the use of URL objects is simply implemented to prevent details of interaction with documents, and the present invention may be readily implemented in other ways. When a call to the URL object is made, the execution flow proceeds to a data update routine 2000 which will be described below with reference to FIG. 20. The change handling routine 1900 then proceeds to block 1914, where it terminates.

Referring now to FIGS. 20A-C, the interaction between the data update routine 2000 and the objects used by the routine 2000 is described. The data update routine 2000 shown in FIG. 20 describes two cases beginning at blocks 2002 or 2004 where data update is performed. In an embodiment where the data update routine 2000 begins at block 2002, the URL object receives a call to perform data update within the context of the change task handler 1250. As described above, the application may include a change operation for modifying the content of the XML document. Thus, the change handling routine 1900 (FIG. 19) may generate a call to perform data update on the particular URL object 1253 received at block 2002.

Once the routine 2000 begins at block 2004, the call to perform data update on a particular URL object 1253 starts from the user interface component. Once the binding is defined, the component will know the XML document associated with the URL and the binding. For example, the Input3 component of the Mytasks application receives the URL object corresponding to the document "data / tasks.xml" when the Bind task 616 is executed. As described in detail below and according to one embodiment, a web browser using an HTML DOM may be used to render the user interface. In this embodiment, the component objects created in the context of the corresponding view object allow various event listeners to be registered on the HTML DOM using a web browser. A component listens to events that affect the HTML DOM, for example, which occurs when a user provides input or interacts with a user interface displayed in a web browser. With particular reference to FIG. 20B, component 1252 makes a call to URL object 1253 that interprets the received data and implements a data update event. For example, if the "Update Presentation" task is deleted from the example MyTasks application, a URL object corresponding to the "data / tasks.xml" document is created and called to delete the task description from the data model. As described in detail below, the URL object 1253 then communicates data updates with the transaction manager 910. In turn, transaction manager 910 propagates the data update to the underlying XML document object that actually causes the data update to be implemented. In addition to implementing the data update, the document object 1254 allows the data update to be charged to all suitable listening data update objects. These listening objects are often components, but can be other kinds of objects. The XML document can be shared across remote computers that listen for changes made to the XML document object. However, data updates to the local document object 1254 maintained in the client-side cache are implemented before the data update is propagated to any remote listeners. In other words, a full network update is performed following a locally implemented data update.

In block 2006 of the data update routine 2000, the URL object 1253 corresponding to the document object 1254 to be updated causes a new transaction to be created. In this regard, transaction manager 910 is called at block 2006 and generates an XML fragment representing a new "transaction" or relative change to the XML document. In one embodiment, transaction manager 910 includes information for implementing and replacing relative changes in the XML fragment. In addition, XBind serialized in XML is included with the transaction generated in block 2006, regardless of whether the data update originates from the component's context or the change operation handle. As described in detail below, the transaction manager 910 allows data updates to be implemented locally and propagated to any remote listeners. In either case, an XBind is provided that identifies XML-formatted data that includes a location in the data model in which the data update is to be performed and logic to return the requested data manipulation operation (hereafter referred to as "rollback" performance).

In block 2008, the transaction manager 910 causes the data update to be implemented locally. A transaction can represent a session that includes multiple and potentially different kinds of modifications to the data model. Thus, upon a data notification event, one or more update event objects are created that represent the unit in which modifications to the data model are described. Transactions, on the other hand, fully describe one or more changes made to the data model and the logic to reverse those changes. In addition, in addition to sending data notification events, document objects provide methods for modifying the actual content of underlying XML documents represented in update event objects. In particular, each data manipulation primitive (replace, append, prepend, insert, etc.) that can be executed on an XML document is implemented in the corresponding methods provided by the URL object 1253, transaction manager 910, and document object 1254. do.

As described in block 2012 of FIG. 20, the transaction manager 910 calls the communication manager 1256 to propagate the transaction to certain remote listeners. In this regard, communication manager 1256 allows applications to instantiate channels that abstract communications with remote network services. Based on the received XBind, communication manager 1256, if any, identifies a suitable communication channel for sending a transaction over the network. As described in detail below, communication channels operate under different protocols as defined by the URL standard. For example, a suitable communication channel may be identified in the protocol identified in the URL, such as "http: //," "xios: //," or "database: //". Using logic obtained in accordance with the communication APIs, the data received from the transaction manager 910 is translated into a format that can be understood by the remote network service. In this regard, systems and methods for performing network communications using communication channels are described in detail below. In particular, the logic for notifying and updating the rotary data listeners is performed before and independently of the corresponding transaction sent over the network. In one embodiment, the present invention is set up to propagate transactions over the network asynchronously. As a result, execution of the application locally is not hindered by network latency or other delays inherent in network communications. Then, if the transaction is provided to the appropriate channel, the data update routine 2000 proceeds to block 2014, where it ends.

Referring now to FIG. 20C, an exemplary networking environment is described that is suitable for describing how transactions are propagated between remote clients. As mentioned above, transaction manager 910 allows transactions or data fragments that represent a relative change to locally stored documents to be propagated to any remote listeners. In the example shown in FIG. 20C, transactions initiated with clients 2080 and 2082 are subsequently sent to an XML file system 2084 maintained at a server side data center. In particular, each client 2080, 2082 propagates transactions 2086-2088 and 2090-2092 to the actively shared document 2093. Any data updates to document objects 2094 or 2096 performed locally in client-side cache 2098 are identified and propagated to XML file system 2084 so that clients 2080 and 2082 can retrieve the data in real time. Can share

Referring now to FIG. 21, an additional description is provided of how rules are applied to provide more intelligent components. When bound to data, certain rules associated with the component apply and assign a namespace unique to the data model. Generally described, rules allow generic components to interpret, learn, and take appropriate action based on the content of the data model. In other words, rules that use components do not need to be created for specific data models. In this regard, the bind handling routine 1600 (FIG. 16) described above may determine whether a particular component uses rules. In this case, the setup rule routine 2100 described with reference to FIG. 21 may be called to apply and merge rules associated with the data binding of the new component. In one embodiment, the unique XML namespace of the rules of the component is merged into the data model and is readily available to components bound to the data model. In another embodiment, rules associated with a component may be stored remotely and may be accessible via web services or additional XML documents.

As illustrated in FIG. 21, the setup rule routine 2100 begins at block 2102, where a decision block 2104 determines whether a rule handler for the appropriate document has been defined. In this regard, rule handlers allow rules associated with different components to be executed on the same data. Each rule-using component bound to an XML document provides logic (eg, "rules") to the corresponding rule handler maintained in the data model. Thus, if a component using the rules has already been bound to the associated document, there is a corresponding rule handler, and routine 2100 proceeds to block 2108, as described in detail below. In this regard, if multiple rule usage components are bound to the same document, the same rule handler can be used for all components. Conversely, if the rule usage component is not already bound to the associated document, the routine 2100 proceeds to block 2106. As detailed in block 2106 of FIG. 21, a new rule handler is created to accommodate the rules of each component bound to the same underlying data.

As described above, a set of generic components of the kind used by modern graphic based applications is provided. By defining the rules, the generic components provided by the present invention need not understand anything about the underlying data model. In this regard, FIG. 8A visually illustrates the hierarchical structure of folders in a file system and describes tree component 800 including folder names, icons, and the like. Rules that provide logic for populating generic tree components with content maintained in the data model can be defined. For example, aspects of the invention may describe the contents of a file system of folders.xml document in which each element of the document represents a different folder. Data associated with particular folders, such as identifiers, icons, and the like, may be identified according to attributes in the folder element. By way of example only, the following rules may be defined to interpret the content in the folders.xml document for display in the tree component 800 shown in FIG. 8A.

<tree name = "folder tree">

<rule match = "folder" display = "@id" />

<rule match = "folder [@id = 'email'] '' display =" @ id "icon =

"icons / mailicon.png" />

</ tree>

 In this regard, the first rule element having a matching attribute of "folder" and a display attribute of "@id" causes the contents of the "id" attribute of the folder.xml document to be displayed as the folder name. Thus, names assigned to folders in the tree component 800 shown in FIG. 8A may be defined using rules. The second rule element with a matching attribute of "folder [@id = 'emair]" causes folders with a name attribute of "email" to be assigned a specific icon associated with email messages as shown in Figure 8A. It is to be understood that the rules provided above are merely exemplary and include only a subset of the logic actually used to create the contents of the tree component 800. If the structure of the folders.xml document is modified, the rules of the component can be easily updated to account for the change. In addition, rule usage components are notified of changes in the same way as other data updates. In particular, an event update object may be created and used to notify the component of changes using the notify listeners routine 2200 of the data update event notification bus, which will be described in detail below.

Referring again to FIG. 21, the rules of the component bound to the data model are applied to block 2108. Once the rule handler is created, the component that is the target of the bind operation provides the rules to the appropriate rule handler. In this regard, the rule handler acts as an extension to the data model and manages the rules of different data binding components that are cornered in the same document. In one embodiment, namespaces may be assigned to a data model that separates terms of different rules using components or objects. By assigning and managing component rules using namespaces, a rule handler can execute all component rules in a way that avoids conflicts within the data model.

When applying the new rules at block 2108, the rule handler is called to cause the rules of each component bound to the associated document to be executed. In other words, rules potentially associated with multiple data binding components are executed with respect to the current version of the data model. Then, when all the rules are executed, the component that is the target of the bind operation will be aware of the correspondingly allocated namespace by the rule handler. In particular, the rule handler passes a reference to the component associated with the new data binding that identifies the namespace in the data model assigned to the component's rules.

 At block 2110 of the setup rule routine 2100, the rules associated with the component that is the subject of the bind operation are merged with the rules of the other components. Developers can use the XML-based languages provided by the present invention to define the semantic logic of the rules of the component. By way of example, a rule may include XPath expressions, UIXML logic references, elements describing other components, variables, aliases, and other references to data outside the repository of the rule namespace. In this regard, data bindings of different components may have a transitive relationship thanks to the associated application and rule logic. Thus, the rules of different components operating on the same underlying data are also maintained in the data model. When a component knows its namespace, a call is made to set new data for the component. In this case, the call to set new data on the component causes the semantic logic of the component rule to be included in the data model of the namespace separate from the rules associated with the different components.

At block 2112, a call is made to propagate data updates reflected in the data model to any data update listeners. As mentioned above, the document object maintains a list of listeners that are notified in response to the data update. When new rules are added to the data model, as occurs at block 2010, corresponding listeners are notified of the data update. In this regard, the logic for notifying the listeners of the update is described in detail below with reference to FIG. The set rule routine 2100 then proceeds to block 2114, where it terminates.

In the above example, bindings have been defined that allow the component to automatically display the content maintained in the data model. By using bindings in this way, developers are freed from having to provide logic in their application code to set up and update data on user interface components. However, the above examples are very simplified and merely reflect one exemplary aspect of the present invention. In this regard, the bindings and corresponding XBinds enable the implementation of complex functionality.

In one embodiment, the present invention provides standardized means for objects to describe, store, and communicate current status. As an example, FIG. 8A illustrates a tree component 800 that allows users to browse and select folders in the file system. User selection can be described in XBind, which provides a standardized variable format in a network operating environment. In the example shown in Figure 8A, the user makes a series of selections to go to a folder named "video_encoding". The state of the tree component 800 regarding the selection of this particular folder can be described in the following XBind.

URL: folder s. xml

XPath: /

Selection: / folders / research / work / video_encoding /

The example provided above is simplified and is used for illustrative purposes only. In a practical embodiment, the XBind describing the tree component 800 is actually as follows.

URL: folders.xml

XPath: /

Selection: / fs: folder / fs: folder [@name = 'research'] / fs: folder [@name = 'work'] / fs: folder [@name = 'videoencoding]

All XBinds described herein can be used to reference data regardless of where the data is stored. Thus, if underlying data is maintained at the network location, the selection is described in the next XBind.

URL: http: //www.networkdomain.com.folders.xml

Base path: /

Selection: / folders / research / work / video_encoding /

  In some cases, other objects often use XBind to describe user selection as a basis for performing operations or implementing application functionality. As illustrated in FIG. 8B, list component 850 displays file system data that may be based on user selection made from tree component 800. For example, the list component 850 can display documents (eg, "whitepaper.txt," "testresults.xml," and "blog.html") based on the folder selected in the tree component 800. Is set. The XBind describing the selection is the output for the data model shared by the tree component 800. In turn, this XBind may be provided as input to other listening objects (eg, list component 850). Thus, input provided to one object (eg, list component 850) is fitted to output already following the data model from the other object. The implementation of XBind provides a generic variable format that allows the insertion of this I / O whose values connected from the data model depend on the values of previous I / Os. In this regard, the internal computational logic of the objects that implement the XML virtual machine are separated from the interaction with other objects and systems. In one aspect, XBinds provide a standardized variable format that is used to model interactions and to separate them. The XBinds provided by the present invention do not contain values for the requested data. Instead, XBinds refer to locations from which data can be obtained, allowing different objects and systems to operate with the same underlying data. In addition, XBinds can be transformed, merged, or serialized for use in XML-based systems. As described herein, XBind serves as a carrier of object state information using the selection aspect of XBind. In particular, since XBinds reference locations from which object state information can be obtained, state information can be communicated without changing or changing the referenced information or objects.

When the user navigates the file system, the tree component 800 can use all the dimensions of the XBind to describe the selection. For example, if the user selects both "whitepaper.txt" and "testresults.xml" documents in the tree component 800, the selection can be described in the next XBind.

URL: folder s. xml

Base path: / folders / research / work / video_encoding /

Selection: / folders / research / work / video_encoding / document [@ name = 'testresults.xml']

     / folders / research / work / video_encoding // document [@name =

'whitepaper.txt']

 Again, the above example is used for illustrative purposes and does not represent an actual embodiment of the present invention. The URL of this XBind refers to the underlying XML document that describes the file system, and the base path restricts the binding to the "video_encoding" folder. The selection of this XBind also includes an array of XPath expressions that identify each document selected by the user. Similar to the description provided above, this XBind can serve as a reference for other objects to perform the operations. As an example, the user generates an event to delete selected documents. The above XBind describing the selection state of the tree component 800 is provided as input to the system implementing file deletion.

 As previously shown, components and other objects are notified in response to changes in the data model. Aspects of the present invention allow components to be registered as listeners for data updates performed on a particular document. When a data update occurs, each listener registered with the document object can be notified of the data update and update the user interface accordingly. Referring now to FIG. 22, a notify listener routine 2200 is described that propagates data updates to listening components. Although the notification listener routine 2200 is described with reference to listening component objects, this is a simple example since other objects may also be data update listeners.

 As illustrated in FIG. 22, the notification listener routine 2200 begins at block 2202 where data updates are performed on an XML document. As illustrated in the above example, data updates to the data model may be performed in different environments. When interacting with the data binding component, the user can generate input that is automatically continued in the data model by the component. On the other hand, the data update may be performed as a result of the execution of the application logic defined in the change operation. In addition, the objects implementing the XML virtual machine perform data updates when using shared data models and bindings as communication interfaces. For example, the semantic description of the rules of a component continues with a data model that allows different components to interpret the same underlying data.

At block 2204, it is determined whether data update has been performed on the document with the corresponding rule handler. If no rule handler is defined because the rule usage component was not previously bound to the document, the result of the test performed at block 2204 is "no" and the notification listener routine 2200 proceeds to block 2208, This is described in detail below. Conversely, if the associated document has a corresponding rule handler, the notify listener routine 2200 proceeds to block 2206.

 At block 2206, the rule handler associated with the document that experienced the data update is called. By invoking the rule handler, logic is implemented to ensure that the rule namespace understood by each data binding component is current and to ensure the integrity of the data model. In this regard, the data update performed at block 2002 may include adding or modifying logic in the rule handler. For example, if a new data binding is defined, the setup rule routine 2100 (FIG. 21) causes the rules of the new component associated with the data binding to be merged into the data model along with the rules of the other components. Any listening components bound to the same subdocument are notified of data updates to the rule handlers within the notify listener routine 2200.

In the setup rule routine 2100 (FIG. 21) described above, the rule handler causes all rules reflected in the current version of the data model to be executed. The component associated with the new data binding is then provided with the current namespace information about the corresponding rules of the component in the data model. However, because the addition of a new rule can affect the bindings of other rule usage components, an update notification is also provided to these rule usage components. Thus, when called at block 2206, the rule handler causes all rules reflected in the current version of the data model to be executed. As a result, the rule handler can provide the current namespace information and up-to-date rules to any listening component that is the rule user. In turn, this new data is set on the component so that the data updates of the new rules are reflected in the data binding of the listening components.

When the rule handler terminates, the "Update ()" method associated with the listening component is called at block 2208. Since components are defined according to component APIs, the logic performed within the "Update ()" method is configurable. In other words, each component does not implement the same logic within the "Update ()" method. Instead, developers can adopt this logic and create new components that effectively extend the capabilities of the XML virtual machine. Thus, the description provided below has been made with reference to the components provided by the present invention and is merely a representative of the logic that may be implemented within the "Update ()" method.

At decision block 2210, a determination is made whether an initial data update has been performed at block 2202. In one embodiment, data updates are directed through transaction manager 910. One or more event update objects representing an atomic unit for implementing data update may be generated and subsequently provided upon a call to the listening component's "Update ()" method (received at block 2208). In one embodiment, if an event update object is received upon a call to the " Update () " method, the data update is not the first update and the notification listener routine 2200 proceeds to block 2214, as described in detail below. do. If no event update object is received in the call to the "Update ()" method, then routine 2200 determines that the initial data update is being executed and proceeds to block 2212.

At block 2212, the component's user interface is visually rendered using the full representation of underlying data bound to the component. Upon reaching block 2212, an initial data update is performed and all data sets on the component should be reflected in the component's user interface. In this regard, the routine for causing XML format data to be rendered in the component's user interface is described in detail below with reference to FIG. However, it should be understood that how rendering is performed is a developer's choice and is not dictated by component APIs. As described in detail below, rendering may be performed by various techniques including, but not limited to, XSLT, JavaScript, HTML, VML / SVG or Adobe ™ Flash.

As mentioned above, one or more event update objects are provided when the "Update ()" method of the listening component is called. As described in FIG. 22, a received event update object representing an atomic unit describing the data update is selected for processing at block 2212. In one embodiment, logic is implemented such that data updates represented in one or more update objects are reflected in the user interface of the listening component.

At decision block 2214, it is determined whether the selected event update object represents a data update affecting the listening component. As mentioned above, the component or task that initiated the data update provides an XBind that references a location in the data model that is affected by the data update. This variable, which describes the changes made to the data model, is contained in the event update objects that are propagated to each listening component. In this regard, XBind is also used to describe the binding of data to the listening component's user interface. In one embodiment, the XBind describing the data binding of the listening component may be compared to the provided XBind describing the data update. The use of a common variable format (eg, XBind) allows the listening component to perform a comparison and determine whether the component's user interface is affected by the data update. If the results of this comparison indicate that the listening components are not affected by data update, the notify listener routine 2200 proceeds to block 2222 and is described in detail below. Conversely, if the data binding of the user interface of the listening component is affected by the data update, the notification listener routine 2200 proceeds to block 2216.

In one embodiment, the present invention supports partial updates to the visual display of the user interface of the component. At block 2216, it is determined whether a partial update can be performed by the listening components. In this regard, if logic is provided within the "Update ()" method that supports partial updates, the notification listener routine 2200 proceeds to block 2220 and is described in detail below. Conversely, if the listening component does not support partial updates, the notify listener routine 2200 proceeds to block 2218 and the "Update ()" method is based on all the data whose user interface is reflected in the component's data binding. To render it. In this regard, the routine for causing the XML format to be rendered on the component's user interface is described below with reference to FIG.

At block 2220 of the notify listener routine 2200, a partial update to the user interface of the component is performed. If partial updates are supported, then only the data affected by the data update in the components data binding is used to perform the partial update. Using the provided XBind, at block 2220, this data can be identified and set on the component. The component's "Update ()" method causes the component's user interface to be rendered based on the partial update now reflected in the components data binding.

At decision block 2222, it is determined whether further updates should be reflected in the user interface of the component. Thus, if the event objects received upon invoking the "Update ()" method were not previously selected, the routine 2200 proceeds to block 2212, where blocks 2212-2220 are selected for each event update object. Repeated until processed. Then, if all changes represented in the data update are reflected in the user interface of the component, the routine 2200 proceeds to block 2224, where it terminates.

As described above with reference to FIGS. 4A-B, the network operating system may be implemented on the client computer, in the context of a web browser, such as a standalone application or machine operating system. In this regard, a rendering routine 2300 that performs processing to graphically render and initialize the components and dialogs of an application is described with reference to FIG. Although specific web browser technologies are specifically referenced below, it should be understood that the present invention may be implemented without a web browser. Also, in other embodiments, the rendering routine 2300 may be implemented differently to account for browser-specific variations. Accordingly, the description provided below with reference to FIG. 23 is merely illustrative and may be performed differently on various platforms.

As illustrated in FIG. 23, the rendering routine 2300 begins at block 2302 where the view object is instantiated and called to render a new application view. As mentioned above, the data type recognizer provided by the present invention causes a new view object to be instantiated when the UI XML document is opened. The view object generates, at block 2304, a request to obtain a new dialog object. Generally described, the dialog acts as a frame for the components of the application and includes controls for minimizing, expanding and manipulating the visual representation of the application's view. In one embodiment, a dialog manager configured to recycle dialog objects is provided to reduce the amount of memory consumed. Thus, if a previously created dialog object is no longer used but is still held in memory, the existing dialog object is reallocated to a new application view.

At block 2306 of the rendering routine 2300, the view object is registered as a listener on the corresponding view.xml document. Similar to the user interface component, the view object registers as a listener for data updates performed on the data model describing the view. As described in detail below, the view.xml document in which the view object is registered as a listener is updated when certain events originate from the web browser. Typically, events are generated by the user when input is provided or when the user interacts with the system.

At block 2308 of the rendering routine 2300, the XML-based description of the user interface of the application is transformed or transformed into an HTML-based representation. As noted above, the present invention allows developers to semantically describe the visual representation of a view of an application using the UI XML language. In this regard, the UI XML programming language does not allow developers to provide any computational or scripting logic. Instead, abstract descriptions of the graphic elements and their relationships are provided in the application's UI XML document. For example, when a web browser is used, XSLT may be defined to transform UI XML logic into HTML or other markup formats suitable for rendering a web browser. In particular, when UI XML logic is modified at block 2308, unique identifiers associated with the components of the application are included in the resulting HTML DOM document rendered by the web browser. When the transformation is performed, the web browser causes the graphical elements associated with the view of the application to be rendered.

At block 2310, an object containing the computational logic of the component is instantiated and the corresponding is associated with the view object. In one embodiment, the UI XML document describing the application user interface logic is traversed. Each component represented in the UI XML document is selected and the corresponding component object is instantiated. In one embodiment, the present invention provides a separation between the computational logic of a component and its graphical representation. In other words, the UI XML description of the visual representation of the component does not contain any computational logic and can be modified in various ways and for various platforms without affecting the behavior of the component. In this regard, the component object instantiated at block 2310 encodes the computational logic of the component, which may be represented in a scripting programming language such as JavaScript, SilverLight, or AAdobe ™ Flash. However, developers do not use scripting languages to define the desired behavior of components. If new components are needed, developers can create new components according to the component APIs. In this regard, each component object implements methods based on information received in accordance with component APIs. These methods include an "Initialize ()" method for setting data on the component and an "Update ()" for performing updates to the user interface of the component. Many methods not discussed here, such as "Upload ()" to remove a component when the application view is closed, can be implemented within the components. However, as long as there are basic methods defined by component APIs, components can be implemented using any available rendering technique. In other words, components are not required to render the user interface in HTML using XSLT, even if it is the embodiment described primarily here. In addition, rendering logic may be described as a component using traditional programming logic.

At block 2312, the operation behavior of the component object instantiated at block 2310 is initialized. When the UI XML logic of the view of the application is modified, the identifiers associated with one or more components are included in the resulting HTML DOM document rendered by the web browser. When initiating the behavior of the components at block 2312, suitable references related to the components of the HTML DOM may be identified by the view object using the view.xml document. By parsing the view.xml document, the view object can instantiate component objects corresponding to the generated HTML DOM and associate each component object with a corresponding user interface. In this way, the operation behavior and logic of the component is invoked on the component's user interface. Once a component is associated with each user interface, the basic states and / or values of the component are set according to the "Initialize ()" method implemented in each component using component APIs. Once all components represented in the UI XML document of the application are initialized, the rendering routine 2300 proceeds to block 2314, where it terminates.

Generally described, the functionality performed by the rendering routine 2300 enables communication between the HTML DOM where the view object is used by XML-based applications and the web browser. In response to the occurrence of the event in the web browser, the affected component and view object are notified, and after processing, the event is processed by the appropriate event listeners (e.g., triggers or event listening objects in the process XML document). Spread to Once a binding has been defined, as described above, when a component corresponding to the "Update ()" method is called on a full or partial update, the graphical representation of the component of the web browser can be changed.

In particular, component APIs require components to implement a basic set of computational logic. As a result, components can be easily set up to use rendering techniques other than HTML, and still be aware of data updates and bind to data. In other embodiments, the components may use AAdobe® Flash, Microsoft® SilverLight, Java® Applet, or other rendering techniques that can be invoked in the computational logic of the XML virtual machine executing the computational logic of the respective client-side components. Can be initialized and rendered. In addition, the rendering routine 2300 described above may be performed in other ways when the present invention is implemented in different kinds of computing devices. When no web browser is used, the user interface logic of the application may be rendered without performing transformation between XML and HTML at block 2308. Instead, it implements and calls the component's user interface within the "Initialize ()" and / or "Update ()" methods, and is built using traditional programming languages such as C, C ++, Java, or Microsoft® SilverLight. Suitable graphic primitives may be provided.

XIOS Communications Overview

XIOS applications written for a network operating system use a Model View Controller (MVC) model. To this end, XIOS applications interact primarily with the data model, which is an abstraction of the contents of the data source. This abstraction layer between the XIOS application and the data source allows the XIOS application to be isolated from the changes made at the data source. In other words, changes in the data source do not necessarily require changes in the XIOS application.

24 outlines an embodiment of how XIOS applications 2402 interact with various example data sources within this framework. In MVC terms, XIOS applications 2402 primarily interact with the data model. In one embodiment of this architecture, XIOS applications 2402 interact with data models for various data sources by interacting with XML documents representing the data model of each data source. In another embodiment, XIOS applications 2402 directly interact with a programming object that exposes a data model, as described above. Although the description below relates primarily to an embodiment where XIOS applications 2402 interact with XML documents, those skilled in the art can understand that other implementations of the MCV paradigm may be substituted.

Communication with a given data source is handled by communication manager 2412, which may be embedded in system context object 902 (FIG. 9) at run time. The communication manager 2412 manages a set of communicator instances, each of which implements a communicator API 2410. Communicator API 2410 exposes generic tasks applicable to any data source. For example, communicator API 2410 loads documents in which XIOS application 2402 connects to a data source, modifies data stored in the data source, creates new data in the data source, queries or removes data from the data source, and the like. , Modify, create or delete.

Communicator API 2410 is built around the concept that any data source can be accessed using just a URL. The communicator that implements communicator API 2410 allows access to data via a URL and returns XML documents that the XIOS application 2402 can manipulate as a data model. Using this simple methodology, the XIOS application 2402 using the returned XML document does not require any knowledge of the channel on which the document arrived, or the type of underlying data source from which it was generated. Having a unified way to use, manipulate, and generate data simplifies application development and implementation of data abstraction solutions. XIOS applications 2402 may change from one data source to another and / or transform a data source.

 Communication manager 2412 instantiates a given communicator to create a channel in response to a request for a URL from XIOS application 2402. The name or type of channel is provided in the URL protocol, and the rest of the URL provides information about the channel. The channel then processes the information in a channel specific manner. For example, a web search channel accepts a URL such as "websearch: // example + search + terms". The protocol "websearch" directs the communication manager 2412 to pass the URL to the search channel, and the location "example + search + terms" can be used by the web search channel to make a search query to be sent to the web search engine. have. As another example of a channel, a message in the inbox of an IMAP folder store can be accessed in a similar manner via an IMAP channel when a URL such as "imap: // servername / userl / inbox / messagel" is passed.

In some cases, a simple URL is passed to a function of communicator API 2410 implemented by a particular communicator, such as a loading function or a storing function. In other cases, the action URL may be passed to the communicator. Operation URLs may be used in the communicator when needed to provide additional functionality except for standard data read / edit / write / paste operations provided by communicator API 2410. The action URL may provide communicator-specific functions that utilize the underlying data model, other resources, or other resources with other resources. One example would be an action URL that allows the communicator to perform complex processing of the underlying data model, thereby relieving the programmer of this processing in the program code. Another example may be to provide functionality based on data or functions external to the underlying data model. The format of the action URL is similar to other URLs that are passed to communicator API 2410. "channel_name: // function (paraml, param2,... param n)" where "channel_name" determines the communicator to process the action URL and "function" is used by the communicator to determine what processing is to be performed. Where "param1, param 2, .. param n" is a list of parameters to pass to the function. In one embodiment, the request for the action URL returns an XML document.

Three examples of data model documents, communicators and data sources are shown in FIG. One example is a data model document 2404 and communicator 2414 used to communicate with a web search service 2426 such as Google, Yahoo !, MSN Live Search, and the like. The XIOS application 2402 requests a web search model document 2404 from the document manager 912 that abstracts communication with the web search service 2426. The document manager 912 uses the communicator API 2410 to communicate with the web search communicator 2414 when the XIOS application 2402 interacts with the web search model document 2404. In turn, the web search communicator 2414 translates the submitted requests into a format understood by the SOAP interface 2420 exposing the functionality of the web search service 2426 via the communicator API 2410. Thus, when the XIOS application 2402 requests a URL such as "websearch: // example + search + terms" from the document manager 912, an XML document such as a web search model document 2402 representing the search results is returned. do.

 Another example shown in FIG. 24 is an SQL model document 2406. Like the web search model document 2404, the XIOS application 2402 manipulates the SQL model document 2406. Changes to this document cause the document manager 912 to call the SQL communicator 2416 via the communicator API 2410. The SQL communicator 2416 translates the call from the communicator API 2410 into a format understood by the SQL web service 2422. The SQL web service 2422 is the front end to the SQL API 2432, which allows access to the SQL database 2428.

As in another example shown in FIG. 24, XIOS applications 2402 can request a document, such as an IMAP model document 2408. When the XIOS application 2402 manipulates the IMAP model document 2408, the document manager 912 communicates with the IMAP communicator 2418 via the communicator API 2410. IMAP communicator 2418 translates requests from communicator API 2410 into a format understood by IMAP web service 2424. IMAP web service 2424 is a front-end to standard IMAP interface 2434 on IMAP server 2430.

Each communicator instance, such as web search communicator 2414, SQL communicator 2416, and IMAP communicator 2418, is hosted by communication manager 2412 of client-side component 2400. The communication manager 2412 is responsible for receiving requests from the document manager 912 including URLs and instantiating the communicators needed to establish a channel in response to each request. For example, when communication manager 2412 receives a request for a URL that begins with imap: //, communication manager 2412 instantiates IMAP communicator 2418 (if not currently instantiated), and requests the IMAP. Pass in communicator 2418.

As shown in FIG. 24, each of the data sources-web service 2426, SQL database 2428, and IMAP server 2430-has a SOAP interface 2420, a SQL web service 2422, and an IMAP web service 2424. It can be accessed through web-based flyers such as If client-side component 2400 communicates only with data sources accessible via HTTP, client-side component 2400 may be responsible for existing communication functionality, such as functionality included in standard web browsers, proxy servers, firewalls, and the like. Receive a lot of reusable benefits. However, it is also possible to create a communicator that does not require an HTTP-enabled data source on the back end. For example, with a suitable communicator, IMAP web service 2424 or SQL web service 2422 are removed, and IMAP communicator 2418 and SQL communicator 2416 are associated with IMAP interface 2434 or SQL API 2432, respectively. You can communicate directly.

XIOS File System-Server-Side Components

25 illustrates an overview of one embodiment of an XML file system server side component 2500. As in FIG. 24, client-side component 2400 includes a data model embedded in an XML-FS model document 2502 made available to XIOS applications 2402 by document manager 912. Document manager 912 communicates with XIOS communicator 2504 hosted by communication manager 2412 via communicator API 2410 when XIOS applications 2402 interact with XML-FS model document 2502. . The XIOS communicator 2504, in turn, communicates with the server side component 2500. Server-side component 2500 includes client interface components 2506 and data storage components 2514.

Client interface components 2506 are primary components in communication with XIOS communicator 2504. XML-based web service 2510 (along with web-based HTTP leaflet 2508) and transaction coordinator 2522 are the main ways in which XIOS communicator 2504 communicates with server-side component 2500. The XML web service 2510 exposes functionality such as file creation, file search, file deletion, file search, and the like within the XML file system. Transaction coordinator 2522, as described in detail below, helps manage changes to files in data storage 2514 when one or more clients are currently connected to the same file, and acts as a caching mechanism. Message server 2512, as described in detail below, notifies client-side component 2400 of changes in objects in XML file system 2500 that XIOS communicator 2504 subscribes to, via XIOS communicator 2504. Is used.

As shown in the diagram, the communication between the XIOS communicator 2504 and the XML web service 2510 is bidirectional. In other words, the XIOS communicator 2504 sends information to, and receives information from, the XML web service 2510. In contrast, message server 2512 primarily pushes information to XIOS communicator 2504.

Data storage components 2514 include a file server 2516, an index server 2518, and a folder database 2520. In one embodiment, the XML file system stores file data in three separate portions. Raw data contained within the file is stored as a file on the file server 2516. File names, authors, modification dates, access control lists (ACLs), and other general file information associated with each file are stored in folder database 2520. Folder database 2520 contains additional folder metadata such as ACLs and associated icons for each folder, the folder rendering type (e.g., indicates that the folder contains pictures, and therefore should be rendered as picture thumbnails), and so on. It also stores the folder hierarchy in which the files are organized. Index server 2518 stores additional metadata that identifies and locates files, such as searching metadata using full text search.

Although these components are shown as separate components on a single server in FIG. 25, those skilled in the art can understand that one or more of these components can be hosted on separate physical hardware. In another embodiment, one or more of these components may be split into a plurality of components, replicated within a server side component 2500, or the functionality may be combined into a single component. For example, an XML web service 2510. ), Message server 2512, transaction coordinator 2522, index server 2518, file server 2516, and folder database 2520 can all be hosted on the same physical machine. ) May be separate from the remaining components, as an independent SQL-based data store, or the file server 2516 may be located on a specialized high performance file storage system. 2500) or a plurality.

 In one embodiment, the XIOS communicator 2504 can always communicate with the same server-side component 2500. The server-side component 2500 may then use the information contained in the URL requested by the XIOS communicator 2504 to determine the appropriate XML web service 2510, message server 2512, etc. to service the request. have. The server side component 2500 contacted by the XIOS communicator 2504 may forward the request together to a more suitable server side component 2500. In this way, client-side component 2400 is isolated from lobe balancing, redundancy, or the scaling architecture implemented by server-side component 2500.

26 illustrates one embodiment of some details of the content of message server 2512. The message server 2512 includes a subscription list for each client using the XML file system. For example, FIG. 26 illustrates two clients, client 1 2606 and client 2 2608. Client 1 2606 is associated with Client 1 subscription list 2602 and Client 2 2608 is associated with Client 2 subscription list 2604.

Each subscription list includes a list of objects stored by server-side components for clients wishing to be notified when the object is updated. Client 1 application list 2602 indicates that Client 1 2606 is a foo.doc (file), bar.doc (also file), user 3, as well as other objects and information stored by server-side components 2500. You want to be notified of changes to the status of the, and changes to the Group 1 folder list. Requests for foo.doc and bar.doc can be sent to the message server 2512 when the files are updated, deleted, renamed, opened by another client, or otherwise changed. Update it. The entry for the state of user 3 is that when user 3 changes state, such as when user 3 goes online or offline, user 3 indicates that he is busy, user 3 enters idle state, etc. Allow 2606 to be updated. An item about a Group 1 folder causes Client 1 2606 to be updated if folders belonging to Group 1 are updated, deleted, have folders added items, or otherwise changed. The items in the Client 2 Subscription List 2604 are similar to those in the Client 1 Subscription List 2602 and behave in a similar manner, but cause Client 2 2608 to be updated as opposed to Client 1 2606. In one embodiment, the notification is sent by message server 2512 via long polling, but other suitable techniques for pushing information to clients may be used instead.

When a client, such as client 1 2606, connects to server-side component 2500 for the first time, client 1 2606 may request, via XIOS communicator 2504, to add the object to the subscription list. In one embodiment, the XIOS communicator 2504 adds the document to the internal subscription list, and in response, the document manager 912 (or other subcomponent of the client-side component 2400) is attached to the XML web service 2510. Issue a request. The XIOS communicator 2504 communicates with the XML web service 2510, which instructs the message server 2512 to add the object to the subscription list for client 1 2606. Since client 1 2606 has never been connected before, message server 2512 generates a new subscription list for client 1 2606, such as client 1 subscription list 2602. This list is identified by key 2610. The key 2610 contains a unique identifier, which is preferably difficult to guess. This key 2610 is sent to client 1 2606 via XML web service 2510 and XIOS communicator 2504 so that client 1 2606 knows key 2620. In one embodiment, the XML web service 2510 and the message server 2512 simply work together to generate a key 2610 that is sent to client 1 2606. In this embodiment, client 1 2606 (as opposed to XML web service 2510) instructs message server 2512 to add an object for client 1 2606 to the subscription list.

As discussed above, a client, such as Client 1 2606, is authenticated by the XML file system upon login to provide security. In one embodiment, this authentication is not copied between message server 2512 and client 1 2606. The difficult-to-guess feature of the key 2610 in this embodiment, in addition to the previous authentication, provides adequate security for third parties who overheard the Client 1 application list 2602. Another advantage of using the key 2610 to provide security for the clients of the message server 2512 is to relieve the load on the message server 2512 as opposed to a more resource intensive authentication technique.

27 illustrates another aspect of an embodiment of a task of a message server 2512. In this figure, message server 2512 is shown with three subscription lists (Client 1 Subscription List 2602, Client 2 Subscription List 2604, and Client 3 Subscription List 2702). During the operation of the XML Web service, transaction coordinator 2522 is notified when changes occur in the objects being monitored. The transaction coordinator 2522 then informs the message server 2512 that the notifications should be sent to all clients who have requested the object.

Those skilled in the art will appreciate that message server 2512 includes a list of subscriptions for each client using an XML Web service, and each subscription list includes an entry for each object that the associated client is listening to. It can be understood that the amount of data stored in the file grows rapidly with the number of clients connected to the XML Web service. A way to reduce the amount of work required by messenger server 2512 is through message chains 2704. Message chain 2704 is a linked list that associates each subscription list listening to a given object. For example, in FIG. 27, message chain 2704 links each subscription list on message server 2512 that is listening to object bar.doc. Through the use of this message chain 2704, if the message server 2512 is notified that there is a change in bar.doc, the message server 2512 first notifies Client 1, then notifies Client 2, By then notifying Client 3, the linked list of message chains 2704 must first be traversed. This reduces processing time and increases the efficiency of the message server 2512 by eliminating the need for the message server 2512 having to determine whether multiple subscription lists contain references to bar.doc. Although one message chain 2704 is shown in FIG. 27, it can be appreciated that there may be one message chain associated with each object in the XML file system currently being monitored by the client.

XIOS File System-File Operations

As mentioned above, the XML file system stores information representing a hierarchy of folders stored in a system in the folder database 2520. The XIOS application 2402 can interact with the folder hierarchy via the folders.xml file retrieved from the XML web service 2510 by the XIOS communicator 2504.

28A-28D illustrate one embodiment of an example method 2800 for retrieving folders.xml file. From start block 2802, method 2800 proceeds to block 2804 where the XIOS application 2402 generates a file subscription to the folders.xml file and submits the file subscription to document manager 912. In one embodiment, the request uniquely identifies a folder and provides a folder identifier ("folder ID") that provides information available to server-side component 2500 to indicate the location of folder database 2520 where the folder information is stored. It includes. The folders.xml file may contain information related to a folder associated with a folder ID and also information related to subfolders within that folder. The folders.xml file may also include additional metadata associated with each folder, as described above. In one embodiment, the request submitted by XIOS application 2402 takes the form of a URL. In another embodiment, the XIOS application 2402 may simply request a folders.xml file from the document manager 912, which generates a URL representing the request.

In one embodiment, the document manager 912 may already have a temporary copy of the folders.xml file, in which case the document manager 912 simply provides the XIOS application 2402 with the temporary copy of the document. . However, the remainder of this description assumes that there is no temporary copy of the requested document in document manager 912. The method 2800 proceeds to block 2806 where the document manager 912 obtains the XIOS communicator 2504 from the communication manager 2412 and passes the file request to the loading function of the XIOS communicator 2504. The method 2800 proceeds to block 2808 where the XIOS communicator 2504 sends a request containing the folder ID for folders.xml to the appropriate XML web service 2510 of the server-side component 2500. Next, at block 2810, the server-side component authenticates the user and routes the request to the XML web service 2510. The method 2800 then proceeds to block 2812, where the XML web service 2510 determines the folder database hosting the folder tree associated with the folder ID based on at least a portion of the folder ID's content. The method 2800 then proceeds to a continuation terminal ("terminal A1").

From terminal A1 (FIG. 28B), method 2800 proceeds to block 2814 where XML web service 2510 queries the appropriate folder database 2520 to retrieve information associated with the requested folder. This retrieved information may include a folder access control list (ACL) and may also include additional folder metadata information. Next, the method 2800 proceeds to block 2816 where the contiguous terminal ("Terminal B") and then the XML Web service 2510 adds folder information to the folders.xml file. In one embodiment, folder information added to the folders.xml file does not include folder ACLs. Instead, the folders.xml file implicitly indicates that the requesting user has at least read access to all the folders in the folders.xml file. More detailed information about the ACLs of the folders can be obtained in this embodiment via a separate request. Examples of some of the advantages of this technique are that the size of the folders.xml file and the complexity of the processing performed by the server side component 2500 are kept to a minimum.

 Here, the folders.xml file interpreted by the XML web service 2510 includes information related to only the folder identified by the folder ID. Requests to the folders.xml file for a given folder also return information about the subfolders of the requested folder. Folder information for multiple folders-each with differently associated permissions (and therefore different ACLs)-is opposed to the client in a single folders.xml file, so only information about folders with matching ACLs It is important to include in the given folders.xml file. To this end, the method 2800 allows the XML web service 2510 to abstract the information associated with the folder database and its associated subfolders, identified by the folder ID including the folder ID and the ACL of each subfolder. Proceed to block 2818, which queries 2520. Using the results of the query, the method 2800 then proceeds to a FOR loop starting with block 282 and a continuous terminal ("terminal C") indicating the beginning of the FOR loop. From terminal C, the method 2800 proceeds to block 2822 where the XML web service 2510 compares the ACL of the subfolder with the ACL of the requested folder. The method 2800 then proceeds to another continuous terminal ("terminal A2").

From terminal A2 (FIG. 28C), method 2800 continues to decision block 2824 where a test is performed to determine if the ACL of the subfolder matches the ACL of the requested folder. If the answer to the test is YES at decision block 2824, the method 2800 returns to terminal B, at block 2816 adds the current subfolder to the folders.xml file, and the method 2800 returns the current subfolder. Repeated in other subfolders. Otherwise, if the answer to the test at decision block 2824 is NO, then the method 2800 will generate an XLINK in which the XML Web service 2510 refers to the subfolder, as opposed to other information about the subfolder, in the folders.xml file. Proceed to block 2826 adding to.

The use of XLINK provides the client with enough information to request a new folders.xml file containing subfolders with different ACLs without exposing the client to information requiring separate authorization checks. This is important because, as mentioned above, the folders.xml file contains an implicit claim that the client can have at least read access to each folder contained therein. If the subfolder has a different ACL than the requested folder (for example, the subfolder is owned by different users, or the subfolders are shared by different groups, etc.) then this implicit assertion is applied to that subfolder. Not true. The use of XLINK ensures that minimal information about the subfolder is provided to the client while the truth of this implicit assertion is still maintained.

If the answer to the test is YES at decision block 2828, the method 2800 proceeds to consecutive terminal C, and the next subfolder is processed. Otherwise, if the answer to the test is NO in decision block 2828, the method 2800 proceeds to another consecutive terminal ("terminal A3").

From terminal A3, the method 2800 uses XML to quickly process future requests for the same folder (assuming there were no changes in the folder hierarchy (assuming that the temporarily stored folders.xml file had to be regenerated) between client requests). The web service 2510 proceeds to block 2830 where the web service 2510 temporarily stores a copy of the complete folders.xml file. Next, at block 2832, the XML web service 2510 returns a complete folders.xml file to the XIOS communicator 2504. The method 2800 proceeds to block 2834, where the XIOS communicator 2504 provides the folders.xml file to the document manager 912. Next, at block 2836, document manager 912 temporarily stores the folers.xml file and provides the folders.xml file to XIOS application 2402. The method 2800 then proceeds to end block 2836 and ends.

28E illustrates one embodiment of a folders.xml file 2840 generated by the embodiment of method 2800 described above. For the purposes of FIG. 28E, the XML file system 2500 stores a folder hierarchy, such as the folder hierarchy shown in tree component 800 of FIG. 8A, and the user creates a folders.xml file for folder " RESEARCH. Assume that you requested it. In addition, a set of line numbers 2842 is included in FIG. 28E for ease of explanation.

As shown in FIG. 28E, method 2800 generated folders.xml file 2840 in response to the request. Lines 1-4 of the file 2840 contain the XML version and schema for the rest of the document. The method 2800 created an entry for the requested folder "RESAERCH" and enumerated the subfolders of the requested folder to add other folders with matching ACLs. In this case, it was found that the folders " PERSONAL ", " WORK " and " LETTERS " and lines 7, 8 and 12 of the file 2840 respectively shown in FIG. 8A had matching ACLs. The method also proceeds to add subfolders with matching ACLs from these folders. In this case, folders "PERSONAL" and "LETTERS" do not have subfolders, but folder "WORK" had two subfolders "BROWSERS" and "VIDEO ENCODING" with matching ACLs found in lines 9 and 10. . For each folder, the method 2800 added limited metadata information to the file 2840. In the embodiment described herein, the method 2800 added metadata that includes "name", "id", and "kind" for each folder, but in other embodiments, more or less metadata is needed. Can be added. Moreover, although the "id" elements have been represented as integers for simplicity, as mentioned above, the "id" values may include more complex information to indicate the folder database 2520 that stores folder information. In another embodiment, simple values such as integer values may be used for the "id" elements, and a lookup may be performed to determine the folder database 2520 that stores folder information.

The method 2800 also created an entry for the folder "EMAIL" that does not have an ACL that matches the ACL of the folder "RESEARCH". The entry for "EMAIL" contains minimal information about the folder, as shown in lines 13-19, showing only the "name" element. Contains an XLINK that can be traversed by the user to create a new folders.xml file containing information about the folder "EMAIL" (as well as any subfolders with an ACL that matches the ACL of the folder "EMAIL"). .

 In one embodiment, the folders.xml file contains information about the folder hierarchy, but does not contain information about individual files in the folder. 29 illustrates one embodiment of a method 2900 for retrieving a list of files in a given folder when the folders.xml file does not contain file list information. From start block 2902, method 2900 continues to block 2904 where the XIOS application 2402 generates a file list request that includes the folder ID of the particular folder and submits the file list request to document manager 912. do. As described above, the folder ID includes information representing a folder database 2520 that stores information about the contents of a specific folder. The file list request may further include additional options such as desired file types, sorting preferences, date range filters, and the like. The method 2900 then proceeds to block 2906 where the document manager 912 obtains the XIOS communicator 2504 from the communication manager 2412 and passes the file listing request to the XIOS communicator 2504. Next, at block 2908, the XIOS communicator 2504 sends the query to the appropriate XML web service 2510 of the server-side component 2500. The method 2900 then continues to block 2910 where the server side component 2500 authenticates the user and routes the request to the XML web service 2510 confirming the permissions for the requested folder 2910. . To verify the permissions for the requested folder, the XML web service 2510 retrieves the ACL for the given parent folder, and checks the folder database 2520 to determine if the ACL grants access to the authenticated user. Inquire

If the user is authenticated and the authorizations are verified, the method 2900 determines that the XML web service 2510 determines the indexing server 2518 corresponding to the requested folder ID, and sends the query to the indexing server 2518 ( Proceed to 2912). As discussed above, the information contained in the folder ID may be used by the XML web service 2510 to determine the corresponding indexing server 2518. Next, at block 2914, indexing server 2518 queries the index to retrieve a list of files for the requested folder and processes the results for the ACL of each file in the list. In one embodiment, the index of indexing server 2518 is a full-text index of information, and the fields indexed for each file include the folder ID of the parent folder. Processing of the result on the ACL of each file in the list ensures that it is added to the folder list only for files that the authenticated user can access. In one embodiment, this processing is omitted to reduce processing time, instead user permissions are enhanced when the user attempts to access one of the files.

Next, at block 2916, indexing server 2518, along with the restricted file metadata retrieved from the index, lists the files returned by the index in a suitable format (e.g., ATOM, RSS or other suitable format). As a feed of, create a format and return it to the client-side component 2400. Restricted file metadata may include items such as last modified date, author, file type, and the like. The method 2900 then continues to end block 2918 and ends.

Since data is collaboratively stored in an XML file system and multiple clients can update a given parent folder or create the same file, in some embodiments the simple creation of a file in an XML file system is a file generation client and server side component. Coordination may be included between aspects of 2500. 30A-30C illustrate an embodiment of a method 300 for generating a file within an XML file system. From start block 3002, method 3000 proceeds to block 3004, where the XIOS application 2402 specifies the file name and destination folder for the new file and initializes the raw file data content. Initialization of the raw file data content may create a new, empty file, or insert existing content into the raw file data (if the user initially stores the content that has already begun to be generated). Next, at block 3006, the XIOS application 2402 submits a file creation request to document manager 912, which includes the file name, destination folder ID, and raw file data content. In one embodiment, at least part of this request is formatted with a URL. The method 3000 then proceeds to block 3008 where the document manager 912 obtains the XIOS communicator 2504 from the communication manager 2412 and passes the file creation request to the XIOS communicator 2504. Next, at block 3010, the XIOS communicator 2504 sends a request to the XML web service 2510 of the server-side component 2500 to create a new file. The method 3000 then proceeds to block 3012 where the server side component 2500 authenticates the user and routes the request to the XML web service 2510.

Next, the method 3000 then proceeds to block 3014 where the XML web service 2510 determines the folder database hosting the destination folder and determines whether the user has permission to create a file in the destination folder. do. As described above, the folder ID of the destination folder includes information that causes the XML Web service 2510 to determine a folder database that includes information associated with the destination folder. As mentioned above, the XML Web service 2510 queries the folder database 2520 to retrieve the ACL for the destination folder, and determines that the ACL has granted appropriate permissions to the authenticated user so that the user can access the file. You can ensure that you have the approval you create. The method 3000 then proceeds to a continuous terminal ("terminal A1").

From terminal A1, the method 3000 proceeds to block 3016 where the XML Web service 2510 checks whether the specified destination folder is a special folder. In one embodiment, there are two kinds of folders in the XML file system: storage folders and special folders. A storage folder is very much the same as a folder in a regular file system, mainly in that it stores files and other folders. Special folders, on the other hand, are used by the XML file system to abstract other forms of communication. This simplifies application development by allowing the XIOS application 2402 to interact with other forms of this communication in the same way that it interacts with files in storage. For example, a special folder may be designated as an email special folder, and the creation of a new file within the email special folder causes the email to be sent. In one embodiment, each user has two special folders: an arrival special folder or "inbox" and a sending special folder or "sent out". In other embodiments, more or fewer special folders exist.

The method 3000 continues to decision block 3018 where a test is performed to determine whether the specified destination folder is a special folder. If the answer to the test is YES at decision block 3018, the method 3000 proceeds to block 3019 where the request is sent to a server process associated with the special folder for further processing. An example of embodiment of that processing is described below with respect to the method 3600 described in FIG. 36 and accompanying text. The method proceeds to a continuous terminal ("terminal B").

 Although FIG. 30B illustrates that a method such as method 3600 occurs before a new file is created in a special folder, this need not necessarily be the case. In one embodiment, the test performed at decision block 30818 may be performed after the file is created, such as terminal B (FIG. 30C). In such an embodiment, the server process that monitors the special folder works on files created in the special folder, as opposed to working directly on requests from clients. The server process is notified of the file creation by polling the contents of the special folder. In another embodiment, the server process is notified of the creation of the file by creating a subscription list associated with the process on the message server or by adding a special folder to the subscription list, thereby, for example, at block 3030 of method 3000. Receive notification from the message server about the creation of the file.

If the answer to the test at decision block 3018 is NO, the method 3000 determines that the file server 2516 allocates space for the raw file data of the new file to a storage location associated with the file server and initially initializes the storage location. Proceed to block 3020, which stores the raw file data. Next, at block 3022, the folder database 2520 creates an entry for the new file in the folder database, which includes the restricted metadata associated with the file, including the file name, creation date, unique file ID, Storage location and the like. In one embodiment, a file may have one or more file streams associated with a single file ID. In that case, file server 2516 allocates separate spaces to storage locations for each stream, and the metadata stored in folder database 2520 associates the file ID with all storage locations. The XML file system exposes all streams associated with the file to the client through the available file metadata.

The method 3000 then proceeds to block 3024 where the folder database 2520 associates the new file with the specified destination folder. The association created between the parent folder and the new file allows the XML Web service 2510 to query the folder database 2520 and the index server 2518 using the folder ID when searching for files stored in the folder. do. The method 3000 then proceeds to another consecutive terminal ("terminal A2").

From terminal A2 (FIG. 30C), method 3000 continues to block 3026 where the XML web service 2510 sends metadata for the new file to the index server 2518. This metadata may be the same metadata stored by the folder database, which is copied to the index server 2518 to enable fast full text search of the metadata. The metadata sent to the index server 2518 may additionally include more information stored in the folder database for full-text indexing to benefit, such as user or application specific attributes, author information, user comments, and the like. . The metadata sent to index server 2518 may also include information abstracted directly from one or more file streams associated with the file.

Next, at block 3028, the XML web service 2510 sends a notification to the message server 2512 that a new file has been created in the specified destination folder. In another embodiment, this notification may be sent by the folder database 2520 or the index server 2518 upon detecting the association of a new file to the parent folder. The method 3000 then proceeds to block 3030 where the message server 2512 sends an update notification to each client having a destination folder specified in the subscription list. Next, at block 3032, the client sends a request to the message server via XML Web service 2510 to add a new file to the client's subscription list, which request includes the file ID. Next, at block 3034, message server 2512 adds a new file to the client's subscription list. The method then proceeds to terminal B, which then proceeds to end block 3036 where the method 3000 ends.

 31A-31E illustrate one embodiment of a method 3100 for opening existing files within an XML file system. From start block 3102, method 3100 continues with a set of method steps 3104 defined between a continuous terminal ("terminal B") and an exit terminal ("terminal C"). The set of method steps 3104 describes a method of opening an existing file that is not shared (that is, a file that is not currently opened by another client). From terminal B (FIG. 31B), the method 3100 proceeds to block 3110 where a XIOS application 2402 on the first client requests a file from the document manager 912, which request includes a file ID. In one embodiment, the request is in the form of a URL. The request may include a file ID incorporated into the newly generated URL, or the first client may already have a URL to access the file, such as a file URL included in the file list. In one embodiment, the URL may not include the file ID itself, but instead includes information from which the file ID can be derived.

 Next, at block 3112, document manager 912 obtains XIOS communicator 2504 from communication manager 2412 and passes the file request to XIOS communicator 2504. The method 3100 then proceeds to block 3114 where the XIOS communicator 2504 sends a request for the file to the appropriate XML web service 2510 of the server-side component 2506, where the request includes a file ID. . As mentioned above, the request may be in the form of a URL that includes the file ID, or may instead include information from which the file ID may be derived. Next, at block 3116, server-side component 2506 authenticates the user and routes the request to XML web service 2510.

 In one embodiment, the file ID or file URL included in the request is such that the XML Web service 2510 determines the appropriate folder database 2520, file server 2516, or transaction coordinator 2522 to obtain the file. To help, it may also include information indicating the file server 2516 where the file exists. In another embodiment, the request may also include the folder ID of the parent folder, and the XML web service 2510 may determine appropriate data storage servers to obtain a file based on the information contained in the folder ID. The number of different servers that must be contacted for a single file request, and therefore the amount of information provided in the file ID or file URL, depends on how the database is partitioned, and the amount of scalability is provided by a particular embodiment. .

 Next, at block 3117, the XML web service 2510 verifies that the user of the first client has permission to open the file and submits a request for the file to the appropriate transaction coordinator 2522. In one embodiment, XML Web service 2510 verifies client permissions by retrieving the ACL for the file from the appropriate folder database 2520 and verifying that the ACL allows authorized users to access the file. At 3118, transaction coordinator 2522 instructs message server 2512 to add the requested file to the subscription list of the first client. The process proceeds to block 3119, which determines whether there is a method 3100. The method 3100 then proceeds to a continuous terminal ("terminal B1").

From terminal B1 (FIG. 31C), method 3100 proceeds to decision block 3120 where a test is performed to determine if the file is currently being shared. If the answer to the test is YES in decision block 3120, the method proceeds to a continuous terminal ("terminal D1"). Alternatively, if the answer to the test is NO at decision block 3120, the method 3100 may determine whether the transaction coordinator 2522 determines a file server 2516 in which to store the raw file data. Proceed to block 3122, which queries. Next, at block 3124, transaction coordinator 2522 retrieves raw file data from a suitable file server 2516. Thereafter, at block 3126, transaction coordinator 2522 returns the raw file data to XML Web service 2510 with the share flag set to FALSE. Next, at block 3128, the XML web service 2510 returns the raw file data to the XIOS communicator 2504 of the first client with the share flag set to FALSE. The method 3100 then proceeds to block 3129 where the XIOS communicator 2504 provides the document manager 912 with access to the raw file data, which in turn establishes a connection to the raw file data with the XIOS application ( 2402). The method 3100 then proceeds to another consecutive terminal ("terminal C").

From terminal C (FIG. 31A), method 3100 proceeds to a set of method steps 3106 defined between terminal D and terminal E, which opens an existing file that is being shared by another client. Explain. For the purposes of this description, this set of method steps 3106 assumes that the set of method steps 3104 has already been executed by the first client and therefore that the requested file has already been opened by the first client. .

 From terminal D (FIG. 31D), the method 3100 proceeds to block 3130 where the XIOS application 2402 on the second client sends a file request through the document manager 912 to the server-side component 2514, The file request includes a file ID. As described above, the request may be in the form of a URL that includes a file ID or in the form of a URL that includes information from which the file ID may be derived. Individual operations, including operations in block 3130, are described in detail below, and thus detailed descriptions thereof are omitted herein for brevity. Next, at block 3132, the server side component 2514 authenticates the user of the second client and routes the request to the XML web service 2510. The method 3100 then checks if the XML web service 2510 checks if the user of the second client has permission to open the file and submits a request for the file to the appropriate transaction coordinator 2522. Proceed to The method 3100 then proceeds to block 3136 where the transaction coordinator 2522 instructs the message server 2512 to add the file to the subscription list of the second client. To those skilled in the art, to date, the similarities between the methods defined between blocks 3110-3116 and the corresponding blocks 3130-3136, that is, to open a shared file and to open an unshared file It can be recognized that there is little difference between the methods.

Next, at block 3138, transaction coordinator 2522 determines whether the requested file is currently being shared. Here, the method of opening a shared file is different from the method of opening a file that is not shared. The method 3100 proceeds to terminal D1 and then proceeds to block 3140 where the transaction coordinator 2522 queries the folder database 2520 to determine the file server 2516 that stores the raw file data. Next, at block 3142, transaction coordinator 2522 retrieves the raw file data from a suitable file server 2516 and temporarily stores a copy thereof. Next, at block 93144, transaction coordinator 2522 instructs message server 2512 to notify the first client that the file is being shared. The method 3100 then proceeds to another consecutive terminal ("terminal D2").

 From terminal D2 (FIG. 31E), the method 3100 proceeds to block 3146 where the transaction coordinator 2522 sends the raw file data to the XML web service 2510 with the share flag set to TRUE. This informs the XML Web service 2510 and the XIOS communicator to treat the raw file data differently than when the file was not shared. Next, at block 3148, the XML web service 2510 returns the raw file data to the second client with the share flag set to TRUE. The method 3100 then proceeds to block 3150 where the message server 2512 notifies at least the first client that the file is currently being shared. The method 3100 then proceeds to block 3152 in which the first client sends any previously unrecorded transactions to the XML web service 2510 in response to receiving a notification that the file is currently being shared.

As described below, when changes are made to the file data model on the first client, the transaction manager 910 of the first client does not immediately transmit these changes to the XML web service 2510 for storage. I can collect it. This can be especially true if the first client is working in offline code, but may also be caused by high network latency, high processor load, and the like. When the first client receives a notification that a file is currently being shared, transaction manager 910 takes the unrecorded transactions and sends them to XML web service 2510.

At block 3154 of method 3100, XML Web service 2510, after receiving these transactions, sends the unrecorded transactions to transaction coordinator 2522, which is the raw stored by transaction coordinator 2522. Records unsaved transactions in a temporary store version of file data. These transactions are eventually written to raw file data on file server 2516. In one embodiment, transactions are recorded when the client receiving the file executes a store command. In another embodiment, changes are recorded when all client users of the document disconnect. Next, at block 3156, transaction coordinator 2522 instructs message server 2512 to notify all listening clients of the recorded changes. The method 3100 then proceeds to block 3158 where the first client and the second client receive a notification of the recorded change from the message server. The method 3100 then proceeds to terminal E and ends.

Network operating system client component startup

32A illustrates one embodiment of a method 3200 for starting a client-side component 2400 of a network operating system. From start block 3202, the method 3200 allows the boot loader of the client-side component 2400 to instantiate a system context object 902 with its associated managers and communicate with the XML file system 2500. Proceed to block 3204 to start the channel. In some embodiments, the use of a boot loader is not required because the XML virtual machine is already included in the client side component 2400. For example, this may be the case in embodiments where the client-side component 2400 is implemented within a mobile device, outside a web browser as a standalone application such as on a set top box or thin client component. This may also be the case for embodiments implemented with a machine operating system that does not require a host operating system for execution. The network operating system operates by retrieving files that define a startup process via a network connection, including but not limited to the use of the HTTP protocol over the Internet. Even without the startup process described in method 3200, the network operating system can operate but the initial setup can be driven by the user manually executing the setup steps.

Unlike traditional operating systems, some embodiments of client-side components may be hosted in other programs, such as, for example, existing web browsers. For those embodiments, special settings related to the startup sequence, including which particular XML file system (s) 2500 connects to or initiates a communication channel, may include host program, HTTP, query parameters, HTTP cookies, or It may be determined by the location URL to go to using other configuration parameters associated with the client (IP, location, machine, browser ID, etc.). For example, directing a web browser to http://os1.icloud.com may cause the client-side component 2400 to connect to the first XML file system 2500 and direct the web browser to http: // os2. Directing to .icloud.com may cause the client-side component 2400 to connect to a second XML file system 2500 that is hosted at a different location from the first XML file system 2500.

 In one embodiment, client-side component 2400 may initiate a communication channel to a data source other than (or in addition to) XML file system 2500 during the startup sequence, connecting to a remote data source or to a local data source. For example, one file system may be a global XIOS file system provided through a service provider data center, another file system connected during the startup sequence may be installed locally on the enterprise network. The first file system can give access to the user's local hard drive Figure 32B illustrates some examples of data sources bound to the client-side component 2400 during startup with drives. The drive of the machine is bound as “Local Drive.” Also, the XML file system 2500 Is bound to “Shared Family Folder.” In another embodiment, the root folder for a group is bound to “Class of 1992 Reunion.” Importantly, each of these data sources is stored in a different location. And differences are hidden from XIOS applications 2402, which see each data source as a simply accessible drive, while these examples are not complete, but they do not have a startup sequence on more than one file system. It is intended to show that a connection can be made: If the user is authenticated, the startup sequence can be continued in a user specific startup sequence that includes connection to additional file systems and initialization of additional channels.

Another difference between embodiments of a network operating system hosted in another program and a traditional operating system is that tasks performed on the host program can interrupt the execution of the client-side component 2400. For example, after the user successfully completes the startup sequence and logs in to the network operating system, the host program may perform the task of reloading the client-side component 2400. In one embodiment, the client-side component 2400 handles this situation by making a login state of the network operating system prior to reloading available to the client-side component 2400 after reloading to recover the state. do. To do this, at block 3206, the client-side component 2400 checks if the user is already logged in. The method 3200 proceeds to decision block 3208 where a test is performed to determine if the user is already logged in. If the answer to the test is YES in decision block 3208, the method 3200 proceeds to a continuous terminal ("terminal A"), thus omitting the login portion of the startup method.

If the answer to the test is NO at decision block 3208, the method 3200 proceeds to block 3210 where the client-side component 2400 opens the login application associated with the communication channel. The specific login application to be launched can be determined by the communication channel, but typically, the login application securely requests the user for user information such as a username and password. Other embodiments of the login procedure exist where login information is requested before boot loading begins, and where the login information is passed directly to the communication channel for authentication without further user interaction. In embodiments without a boot loader, client-side component 2400 may pass login information directly to a communication channel for authentication. Variations may occur when the boot loader, directly loaded, requests login information on its own and then passes the information to the communication channel without using a separate login application. Next, at block 3212, the communication channel processes user information. The communication channel can process user information by sending them to an authentication service or by processing them locally.

 The method 3200 then proceeds to terminal A. From terminal A, the method 3200 proceeds to block 3214 where the communication channel provides the user's setting.xml file to the client side component 2400, where the client side component performs a user specific startup sequence and all the specifics. Use the setting.xml file to mount the virtual drives. The communication channel may obtain a setting.xml file from a remote data server, obtain a setting.xml file from a local data source, or generate a default setting.xml file based on communication channel specific defaults. The setting.xml file contains a collection of user specific settings for setting up the network operating system. These settings include the user name, email address, various application settings, a collection of virtual drives (communication channels) to be explored at startup, and the associated root folder ID (including groups, described below), friends list, and startup sequence. It includes, but is not limited to. The startup sequence contained in the setting.xml file specifies what programs the client-side component 2400 should start, including which desktop manager, console, or startup application to open after successful login. The method then proceeds to end block 3216 and ends.

 In some embodiments, the setting.xml file is a passive repository of metadata representing various items in the network operating system, and the startup application plays a more central role in running the startup sequence. For example, in one embodiment, a startup application runs and then runs a second application, such as a desktop application that displays the desktop to the user. This sequence was executed by the startup application in this embodiment, but the startup application can nevertheless determine which second application should be run by querying the setting.xml file.

Network Operating System Groups and Friends

In a network operating system, groups are used to enable fast and efficient collaboration and file sharing between users. Unlike other systems, it is very lightweight to enable the creation of new groups, collaboration and file sharing in network operating systems. For example, in one embodiment, a user simply needs a right click to create a new group, which automatically creates a common storage folder and allows members of the group to exchange messages and interact with other members of the group. It creates new identities for action and allows you to collaborate with others in real time.

A group, when created, stores a collection of group information. This group information includes a root folder ID, which serves as a reference to the storage location in the XML file system, as described above. Folders and files located in this storage location are only accessible to members of the group. As discussed above, upon starting the client-side component 2400, a settings.xml file is obtained for the logged in user. This settings.xml file contains a collection of references to the groups of which the user is a member. These references may be provided to the client manager component 2400 to mount the group as if it were any other storage location or file system by providing a communication manager 2412 with a reference to the desired group to initiate a communication channel with the appropriate communicator. Used by.

33 illustrates one embodiment of a method 3300 for mounting a group of network operating systems. From start block 3302, the method 3300 proceeds to block 3304 where the client side component 2400 initiates a communication channel for the group. Next, at block 3306, the communication channel processes user information associated with the user. The communication channel can ask the user for additional user information specific to the group, such as membership name and password, or can reuse user login information for simple single sign-on. Assuming that the communication channel can verify the user information, the method 3300 then proceeds to block 3308 where the communication channel obtains the group folders.xml file using the root folder ID obtained from the user settings.xml file. Proceed. Next, at block 3310, the client-side component 2400 adds a reference to the group folders.xml file to an existing folders.xml file on the client. (Creation of an existing folders.xml file has been described above with reference to FIGS. 28A-28D.) This reference represents a virtual communication manager XML document channel #CommunicationManager that contains a list of all open communication channels on the client. Next, at block 3312, the communication channel, if present, obtains an autostart.xml file for the group, and the client-side component 2400 executes instructions or applications specified in the autostart.xml file. This autostart.xml file is common to group administrators, such as auditing programs, welcome screens, common desktop settings, communities representing groups, etc., which should always be executed when logged in by group members. Allows you to specify programs. Groups may specify alternative startup sequences that a user may choose to have with their user startup sequence upon system login. The method 3300 then proceeds to end block 3314 and ends.

In some embodiments, the method 3300 may be used to mount file storage locations because the file storage locations have most of the same characteristics, etc. of groups. File storage locations do not have the concept of having associations that are members of file storage locations (described above with respect to groups), but the process for mounting a file storage location and access to the files in it are very similar. File storage widgets may also be included in the autostart.xml file described above.

Group functionality or file storage locations may be used to implement communities. The file storage location can be used to create communities that do not require a particular membership. In other words, all users can be members of the community automatically. Group functionality, on the other hand, may be used to create member-only communities.

 The above-mentioned group information may include a collection of memberships. Membership is the association between a user and a group and represents the fact that a user is a member of a group. Each membership can contain an associated name that will be shown to other members of the group, thus creating a new identity for that user when interacting within the group. Membership names can be generated by the user when joining a group, so that the user can join groups with widely varying topics while maintaining their privacy. For example, a group named "Group One" may have a collection of memberships indicating that both a user with username "Alice" and a user with username "Bob" are members of Group One. The first membership, which indicates that Alice is a member of Group One, can be the same as or similar to Alice's username, such as "AliceGourpOne". The second membership, which indicates that Bob is a member of Group One, can be different from Bob's username, such as "AnonymousGroupMember". When Alice searches for other group members, she is given access to a list of membership names, but not the associated usernames. Therefore, she can see that "AnonymousGroupMember" is a member of the group, but does not know that "AnonymousGroupMember" is actually associated with "Bob". In another embodiment, members in a group may choose to aggregate the associated username, in which case Alice may know that "AnonymousGroupMember" is associated with "Bob."

Messaging services can handle many identities of users in inter-user communication. This also applies to the handling of friends in the system in that a user can have the same friend in his friends list as two different participants without knowing if they are actually the same person. The user may receive different instant messages from two different participants without knowing that they were sent from the same person.

Transitioning between online and offline states

In some embodiments of the network operating system, client-side component 2400 may operate in normal, online and offline states, while client-side component 2400 does not have access to any server-side resources. The benefit of providing this functionality at the client side component 2400 is that the client side component 2400 helps to seamlessly support a single application operating in both online and offline modes, while Reduce the amount of work required of application developers to support it.

34 illustrates one embodiment of a method 3400 for transitioning a client-side component 2400 of a first client from online to offline. This method 2400 assumes that the client-side component 2400 of the first client has already started up and connected to the XML file system 2500 via a method such as method 3200. From start block 3402, the method 3400 sends a notification to the XML Web service 2510 of the XML file system 2500 so that the client-side component 2400 of the first client takes the state of the first client offline. Proceeds to block 3404, where it is set. This state can then be checked by other clients using the same XML Web services to determine if the first client is offline. Next, at block 3406, the XML web service 2510 instructs the message server 2512 to send a notification that the first client has gone offline to all other clients who have subscribed for the status of the first client. . Typically, other clients associated with the same group as the first client, connected to the XML file system 2500, add the first client to their subscription list on the message server 2512. Notifications are sent by the message server 2512 in the same way as notifications about updates, as described above.

In order for the client-side component 2400 and the applications executed by the client-side component 2400 to continue functioning without having a connection to the XML file system 2500, the client-side component 2400 may be configured from the XML file system 2500. Any necessary resources should be temporarily stored on the first client. To this end, the method 3400 causes the application manager 904 of the first client to download the unprocessed, undownloaded resources present in the application package associated with each instance currently running by the client side component 92400. Proceed to block 3408. The application developer may indicate which resources in the application package must be temporarily stored by the client-side component 2400 to enable offline use of the application. In another embodiment, the client-side component 2400 may automatically determine what resources should be temporarily stored by analyzing the references used by the components of the application package.

 In some embodiments, the application manager 904 may perform additional, optional steps to determine what resources should be temporarily stored on the first client. For example, the method 3400 may proceed to block 3410 where the application manager 904 of the first client downloads certain resources that are dynamically loaded by each instance. These resources are not referenced by the application package associated with the instance, but can instead be determined by the instance during execution. The method 3400 may then proceed to block 3412, where the application manager 904 of the first client downloads resources associated with each open view file. As with dynamically loaded resources, each open view file can be associated with resources that are not referenced by the application package. The method 3400 may also proceed to block 3414 where the application manager 904 similarly downloads resources associated with each process. Those skilled in the art will appreciate that blocks 3410-3414 are optional, so that one or more blocks may be executed in an embodiment of the method 3400, or none of the blocks may be executed.

 Resources are downloaded at block 3408, and after zero or more blocks 3410-3414, the method 3400 sets the system flag on the client side component 2400 of the first client indicating that the first client is offline. Proceeds to block 3416. This system flag can be used to change the behavior of both the client side component 2400 and the applications running on the first client. For example, in one embodiment, the method 3400 allows the client side component 2400 of the first client to perform subsequent file operations, instead of immediately sending file operations and transactions to the XML file system 2500. Queue and continue to block 3418, where each channel of the first client temporarily stores subsequent transactions describing modifications to the file. Because the client-side component 2400 queues file operations and temporarily stores transactions while offline, users of the network operating system are not allowed to make any changes by the client-side component 2400 when the first client is offline. Applications may change their behavior based on system flags, such as disabling functionality requiring network connectivity. The client-side component 2400 itself may further change its operation, such as displaying an error message, if a user of the first client attempts to perform an operation that requires network connectivity. The method 3400 then proceeds to end block 3420 and ends.

35 illustrates one embodiment of a method 3500 that comes back online when a first client already executes a method such as method 3400 and operates offline. From start block 3502, the method 3500 proceeds to block 3504, where the first client is online and the client-side component 2400 of the first client sends an online notification to the XML web service 2510. Proceed. The first client may be online by establishing or resetting a connection with one of a local area network, a wireless network, a dialup network, and the like, but not limited to this. In another embodiment, the first client may be online if the network connection is already established when the user indicates a desire to go online. Next, at block 3506, the XML web service 2510 instructs the message server 2512 to send a notification that the first client has gone online to all clients to which the first client has subscribed for status.

The method 3500 then proceeds to block 3508 where the transaction manager 910 of the first client downloads changes to documents temporarily stored on the first client from the XML web service 2510. In one embodiment, these downloaded changes are changes made to documents in the XML file system 2500 by other clients while the first client is offline. Next, at block 3510, the transaction manager 910 of the first client resolves conflicts between the temporarily stored documents and the downloaded changes. In one embodiment, transaction manager 910 only detects the presence of a conflict, manually creating a new file containing temporarily saved changes, deleting temporarily saved changes for downloaded changes, etc.). You can ask to resolve the conflict. In another embodiment, transaction manager 910 executes an algorithm that determines what changes should be maintained and which ones should be discarded.

Next, at block 3512, the transaction manager 910 of the first client sends the queued file tasks to the XML web service 2510. For example, if a user of the first client attempts to create, delete, and rename some files in the XML file system 2500 while offline, file operations may then be sent to the XML file system 2500. Can be. In one embodiment, the XML file system 2500 detects and appropriately responds to conflicts with changes made by other users (such as attempting to rename a file that has already been deleted).

The method 3500 then contacts the message server 2512 via the XML web service 2510 to the client-side component 2400 of the first client to re-add the monitored objects to the subscription list of the first client. Proceed to block 3514. Next, at block 3516, the client side component 2400 of the first client sets a system flag indicating that the first client is online. In one embodiment, setting this system flag returns the client-side component 2400 and applications to their normal, networked working state. The method 3500 then proceeds to end block 3518 and ends. Here, the XML file system of the first client is then synchronized with the server side component 2500 of the network operating system and brought online.

XML File System Special Folders

As described above, certain folders in the XML file system 2500 may be designated as special folders. In one embodiment, the item for the special folder is stored in the folder database 2520 in the same way as the item for general folders, but a flag is set indicating that the folder is a special folder. In one embodiment, an item in the folder database 2520 for a special folder may include an indication of one of many server processes that process a request to create files in the special folder. In another embodiment, one server process handles all requests to create files in a special folder and determines how to handle the file according to the content of the file, such as the file type of that file.

 These special folders can serve as an abstraction for some other data handling routines, such as asynchronous messaging between users, instead of providing file storage. One example of such asynchronous messaging may be the use of an outbox to receive and process outgoing messages intended for other users. The use of special folders for inter-user communication offers many advantages. For example, it simplifies client application development. The XIOS application 2402 can use the messaging protocol associated with the special folder simply by using the familiar file creation routines and need not struggle with the underlying details of the communication protocol. As another example, the use of special folders for inter-user communication allows the XIOS application 2402 to affect the group functionality included in the XML file system 2500, as described above. Therefore, an application 2402 using special folders for XIOS messaging does not need to add additional code to implement security, group membership, friend lists, addressing, anonymity, etc., an XML file for those features. This is because the underlying functionality of the system 2500 may be relied on.

 36 illustrates one embodiment of a method 3600 for processing a request to create a new file in an outbox special folder. Although the request appears to be a request to create a file to the XIOS application 2402 running on the client, the server treats the request as a request to send a message to a second user. From start block 3602, the method 3600 proceeds to block 3604 where a server process associated with the outbox folder of the first user receives a request to create a new file in the outbox special folder. Next, at block 3606, the server process abstracts the address of the intended recipient from the request. The method 3600 proceeds to block 3608 where the server process identifies a second user associated with the address of the intended recipient.

 The group and friend list functionality of the XML file system 2500 described above allows many different kinds of addressing to identify the second user. For example, the first user may directly address the message with the second user's username. As another example, the first user may address the message with a membership name associated with the second user. In this case, the anonymity of the second user is guaranteed, but the first user can still address the message as the second user. As another example, the first user may address the message with an address stored in metadata associated with the second user, eg, a telephone number. The server process determines what kind of addressing has been used and thus identifies the second user.

 Next, at block 3610, the server process determines the inbox folder ID of the second user. In one embodiment, this simply includes searching the folder database 2520 for the inbox folder associated with the second user. The method 3600 then proceeds to block 3612, where the server process creates a new file in the inbox folder of the second user, using the inbox folder ID, the new file containing the data included in the request. In embodiments where a file is created in a special folder (as opposed to a server process that directly handles a file creation request), the server process simply moves the new file from the Outbox folder of the first user to the Inbox folder of the second user. . The method 3600 then proceeds to end block 3514 and ends.

Example Application-Chat

 As highlighted above, the benefits of the network operating system are that the features embedded in the network operating system are reusable and scalable, cross-platform, and rapidly collaborate on components that include rich security and anonymity functionality. To develop. One embodiment of an example application that takes advantage of many of these features is a chat application, described below.

FIG. 37 illustrates one embodiment of a shared data file 3710 corresponding to chat application 3700 at a higher level. Instead of devising and coding new communication protocols and authentication methods, the chat application 3700 facilitates communication between participants in the chat conversation through the use of a shared data file 3710 present in the XML file system 2500. To perform. The interface of the chat application 3700 includes four main components, a host window component 3712, a text display component 3702, a text item component 3704 and a button component 3706. At the start of a chat conversation, text display component 3702 is bound to shared data file 3706 via binding 3708 such that changes made to shared data file 3710 by any participant in the chat conversation are text display component. 3710 (this text is omitted for clarity).

FIG. 38 illustrates that, at a higher level, the text display component 3702 and the button component 3706 of one embodiment of the chat application 3700 are also bound to the shared data file 3710. When a user enters text into text item component 3704 and clicks button component 3706, changes are made to shared data file 3710. This change is then propagated to all components bound to the shared data file 3710, including the text display component 3702.

 FIG. 39 illustrates the updating of the shared data file 3710 during a chat conversation between the chat application of the first user 3902 and the chat application of the second user 3904 at a higher level. In this figure, both the text display component 3702 of the chat application of the first user 3902 and the text display component 3702 of the chat application of the second user 3904 are both bound to the shared data file 3710 and thus shared. The contents of the data file 3710 are displayed. A first user enters text into text input component 3704 and clicks button component 3706. Button component 3706 is associated with a trigger, which, when the button component is clicked, reads text from text item component 3704, attaches text 3906 to shared data file 3710, and text item component 3704. Make sure the steps to delete the text in.

This procedure of updating the shared data file 3710 requires that the developer simply associate the four components described above to enable this functionality and create a rule that is bound to the text item component. Helps to show at least one advantage. Beyond the scenes, the network operating system handles numerous details of updating the shared data file 3710. For example, in one embodiment, a copy 3710 of the temporarily stored shared data file is stored in a client-side cache maintained by document manager 912. The corresponding URL object receives a request to update the shared data file 3710, which causes the transaction manager 910 to create a transaction that represents the changes. The transaction manager 910 propagates the transaction to remote listeners by causing the transaction to be submitted to the XML web service 2510 via the XIOS communicator 2504 and the XIOS channel. The XML web service 2510 mentions that the file has been shared and forwards the submitted transaction to the transaction coordinator 2522. Transaction coordinator 2522 then records a transaction that updates shared data file 3710 within the XML file system.

40 illustrates the transmission of a chat message via propagation of a change to the shared data file 3710 in one embodiment of the chat application 3700 at a high level. As discussed above, the text display component 3702 of the chat application of the first client 3902 and the chat application of the second client 3904 is bound to a shared data file. Therefore, when the XML file system 2500 updates the shared data file 3710, each bound component is notified of the change and is therefore updated.

 Advantageously, this allows the developer to have UI components that automatically display the correct information always synchronized to the shared data file 3710 via data update event propagation, instead binding the component to the shared data file 3710. Thus, the chat communication can be completed without writing any code. Like updating the shared data file 3710, the network operating system handles a number of details of this transaction. For example, in one embodiment, when transaction coordinator 2522 records a transaction, message server 2512 indicates that shared data file 3710 has been updated on each client that has subscribed for a change in shared data file 3710. Instruct to notify. Message server 2512 sends these notifications to each client, which clients contact XML file system 2500 to abstract updated information from the notification or to obtain the latest version of the file. In this regard, the transaction manager 910 of other clients recognizes that the change has been submitted by the first client and does not repeatedly update the temporary store version of its shared data file 3710. Transaction managers 910 of other clients allow changes to be incorporated into the temporary storage versions of their respective shared data file. As other data updates occur, listening components, including text display components 3702 of the chat application of the first client 3902 and the chat application of the second client 3904, are notified that the file has been updated. Text display components 3702 are automatically updated accordingly with the added content 3906.

41 illustrates additional features made possible by using shared data file 3710 for collaborative communication between clients. That is, updates to a given shared data file 3710 are propagated to any number of clients who have subscribed to the shared data file 3710, so no additional work is needed to enable collaborative communication between two or more participants. . As shown in FIG. 41, the conversation between the first client 3902 and the second client 3904 is made by any number of other clients, such as the third client and the fourth client, without any additional design changes. Can be participated. Each client is bound to shared data file 3710 and receives the above-described updates.

The addition of contacts to a given user's chat buddy list and the setting up of individual chat sessions also account for many of the features included in the network operating system. In one embodiment, the first user may only exchange chat messages with a second user who is a member of a friend list of the first user and who has agreed to chat communication with the first user. The friend list of the first user may be stored in a document in the XML file system 2500 or may be stored and transmitted in a portion of the settings.xml file. To add a second user to a friend list, the first user must first search for the user. In one embodiment, to preserve the anonymity of users when belonging to a group, the first user can only retrieve membership names, each membership name being associated with the user and the group to which the first user belongs. In one embodiment, the first user may also search for a global group, where there is an indication of the user's real name, but no link to the name found in the groups.

 In either case, the search returns to the first user the address associated with the second user. The first user then sends a request to the second user's address to add the second user to the friend list of the first user. In one embodiment, this can be done using the method 3600 described above, where the first user creates a file that configures a friend list request in the Outbox folder of the first user, which is then routed by a server process. And sent to the Inbox folder of the second user. On the client of the second user, the request is retrieved from the inbox of the second user and a dialog is displayed asking the second user if the first user wants to add to the friend list. When the second user responds, the message is sent back to the first user in a similar manner to end the addition of the second user to the friend list of the first user, who then starts a chat conversation with the second user. Can be.

 A similar process occurs for a first user to start a chat session with a second user. The chat application of the first user creates a shared data file 3710, binds the text display component 3702 to the shared data file 3710, and sends a request to start a chat session to the address of the second user. The request is delivered as described above. If the second user accepts the request, a notification is sent to the chat application of the first user, which then sends the document ID of the shared data file 3710 to the chat application of the second user. The chat application of the second user binds its text display component 3702 to the shared data file 3710, and the chat conversation proceeds as described above.

Although these features have been described with reference to chat, those skilled in the art can appreciate that server-mediated communication, such as message boards, email, and the like, can be implemented using shared data files. In addition, shared data files can be used to coordinate other forms of communication that do not require a server for arbitration. For example, a first user and a second user may use a shared data file to negotiate bandwidth settings, cryptographic settings, and the like for peer-to-peer communication such as VOIP or video conferencing.

 Moreover, while the description of chat above handles all messages arriving at the Inbox folder for simplicity, it is also possible for an additional component on the client to manage the incoming messages. In one embodiment, the component on the client analyzes each message shown in the Inbox folder and determines the appropriate application to process the message. The component then starts the application and passes the message to the application for further processing. In this way, incoming chat requests or friendless requests can be handled without having a chat application already running.

  42 illustrates another advantage of using reusable components in creating XIOS applications. The figure describes one embodiment of a network operating system hosted in a web browser and may represent how the network operating system is viewed in other embodiments, such as a standalone application or a machine operating system implementation of client-side component 2400. . Each box in the web browser represents a XIOS application 2402 created with reusable components such as an email component, a clock component, a web search component, a group message component and a weather forecast component. Contrary to simply being in a standalone chat application, the box at the bottom right shows the reuse of chatty application components in this web browser. Since components do not have to be rewritten to work in other contexts, the use of reusable components enables rapid development of such complex applications. Another advantage of creating complex applications is that underlying data that is given to an application from data models can be merged from a plurality of heterogeneous sources, thus allowing applications to operate from the synthesis of multiple data sources.

Example Application-Alumni

43 illustrates an example collaboration application easily created using embodiments of the system. The 1992 Class Alumni Association application is an example of the functionality that can be provided to members of a group. As described above with reference to FIG. 42, FIG. 43 illustrates a collection of components that reference a plurality of data sources. Described by the 1992 Class Alumni application is a collection of components that begins as part of the autostart.xml file that is loaded when binding a group folder. As shown in FIG. 32B, the 1992 Class Alumni Group Folder can be bound to the client as a data source, in which case it is displayed as a drive within the user interface. When the user subsequently opens the data source (or when the user first binds the data source), the autostart.xml document associated with the group folder is delimited by components such as Schedule of Events, the Map to Reunion Events, the Countdown to Reunion, and so on. Causes the vowel to be displayed.

With automatic display of these components, group functionality also provides security. For example, only members of a group can see items in the Photo Album, which can be views of folders stored within the group folder hierarchy. Group functionality also provides easy collaboration with other members of the group, as shown in the Chat component of FIG. 43, which allows users to add other online members of the group without requiring the user to add other group members to the friend list. Shows.

Example Application-Gesture-Based Collaboration

Existing systems for use in collaboration over a network may include multiple applications such as email, instant messaging, workflows, and the like. In this regard, allowing entities to interact and collaborate in a networking environment typically includes the exchange of documents and messages using various tools and applications such as email, instant messaging, and / or conferencing. Alternatively, a centralized repository or network portal can be implemented to centralize the collection and distribution of data for the purpose of supporting collaboration. However, these existing systems do not provide efficient ways of collaboration that can be easily understood by the user. In one embodiment, aspects of the present invention support gesture-based collaboration where users collaborate over a network in a more natural way to simulate real life collaboration.

Referring to FIG. 44, the following is intended to provide an overview of a networking environment 4400 that may be used to describe additional aspects of the present invention. As illustrated in FIG. 44, the networking environment 4400 includes a server-side data center 4402 connected in communication with each of the clients 4404, 4406 via a network 4407. As discussed above, client-side components of the network operating system may be dynamically delivered from server-side data center 4402 to each of clients 4404 and 4406, or may be installed locally. In both cases, the client-side component of the network operating system provides an XML virtual machine 4408 to interpret XML structured applications or to run on each of the clients 4404 and 4406.

In the embodiment shown in FIG. 44, collaboration manager 4410 and state manager 4412 are implemented within client-side components of the network operating system. These managers 4410 and 4412 support collaborative sessions in which a running application is actively shared and visually rendered on remote computing devices (eg, clients 4404 and 4406). The same application user interface (including application state and associated data) can be rendered and manipulated by each user. State changes, including the application, are synchronized in real time with each of the clients 4404, 4406 included in a collaborative session that uses the XML virtual machine 4408 locally to interpret the changes. In one embodiment, to begin a collaboration session with another user, the user may “drag and drop” the application to the boundaries of the visual display. When this type of indicator is received, the collaboration manager 4410 enables the establishment of a collaboration session so that messages describing the application state can be exchanged freely. In this regard, an application running on a source client can be dynamically delivered to other clients on demand. In one embodiment, collaboration manager 4410 allows all resources associated with the application package, as well as application status information, to be sent to the destination client. As a result, the destination client does not need to have any prior knowledge about the application to be included in the collaboration session. Instead, only those resources required by the destination client can be sent, for example when the application is already available on the destination client. As soon as a collaboration session is established, state manager 4412 on each client receives notification of locally occurring state changes. As mentioned previously, the state of all components of the system are propagated to the state XML document provided by the stem to take advantage of the functionality encapsulated by state manager 4412. In particular, this embodiment facilitates synchronization of state for the application on each client 4404 and 4406 participating in the collaboration session. Moreover, data updates affecting documents bound to shared applications are propagated as data update events. Similar to the chat application described above, the user interface component always displays accurate information synchronized via data update event propagation using a shared data file. For example, in an embodiment, when the transaction coordinator records a transaction that includes a data update, the message server instructs each client to join the collaboration session to subscribe to the data update event. In turn, the message server sends these notifications of data update events to the listening client. As described in more detail below, additional objects and managers provided by the present invention are used to implement gesture based collaboration, and the block diagram described in FIG. 44 is merely illustrative.

Referring to FIG. 45, the collaboration start routine 4500 establishes a collaboration session between remote objects to be described. As shown in FIG. 45, the collaboration start routine 4500 begins at block 4502 where an instruction to begin a collaboration session begins. In one embodiment, gesture-based collaboration is performed at the operating system level without developers requiring complex descriptions involved in actively sharing applications between remote clients. As mentioned previously, a user may “drag-and-drop” an application view across the boundaries of a visual display to generate instructions for initiating a collaboration session with another user. In this regard, the location on the visual display may be associated with a particular user based on system settings or other configuration information. In other embodiments, the list of users or other objects associated with the username may be used for gesture-based collaboration. As mentioned above, XIOS applications do not need to add additional code to implement any functionality such as security, group membership, friend lists, addressing, anonymity, etc., depending on the network operating system for those features Because it becomes. These objects used in the application can be encoded to understand the gestures that enable collaboration. For example, a special object "drag-and-drop" may be launched over the application's username so that a collaboration session can be initiated. However, gesture-based collaboration can be implemented in other ways without departing from the scope of the claimed technical features.

At block 4504 of the collaboration start routine 4500, the starting client and one or more destination clients exchange invitation / accept messages. In particular, the collaboration manager 4410 on the originating client receives the command to start the collaboration session created at block 4502. In response, an invitation message is sent from the originating client to the server-side data center 4402. For example, the invitation message is stored in the outbox special folder associated with the first user maintained by the XML file system. As noted above, the creation of a file in the outbox special folder is monitored by one or more servers handling the new file by requesting a second user to send a message. However, this is one way to send an invitation message to the second user to start the collaboration session. In this regard, the invitation message may be returned by the destination client from the second user's inbox. In one embodiment, a dialog may be displayed upon an input request as to whether a second user wants to join a collaboration session. When the invitation is accepted, the accept message is delivered to the originating client in a similar manner. Those skilled in the art can appreciate that the collaboration environment described herein is not limited to supporting collaboration between users. Instead, the user can collaborate with an application that has automated implementation of functionality based on the received input.

When an accept message is received, the starting client implements functionality for the application “export” to be shared. In particular, the received accept message is routed to the collaboration manager 4410 on the originating client. In response, the collaboration manager 4410 implements functionality at block 4506 to provide the second user with temporary access to resources associated with the application. As mentioned above, the application resources needed to run the application may be referenced within the application package or directly embedded. To support collaboration, appropriate application resources are identified along with any documents currently bound to the application. At this time, settings are set for providing the second user with temporary rights to these resources and documents. In particular, resources associated with an application package may include an XML document that provides a semantic description of the application's view and process logic. Thus, an application running on the starting client can be delivered to other clients dynamically on demand. After the application is delivered as a service and the temporary permission is provided to the second user, the destination client does not need to have any previous knowledge about the shared application.

At block 4508 of the collaboration start routine 4500, a unique name is generated for the application delivered by the source client. The destination client can run an application assigned the same name as the delivered application. To differentiate application instances and collaboration sessions, a unique name is assigned to the passed application instance. In one example, a hash algorithm is applied to the identifier associated with the first user to generate a unique application name at block 4508. However, unique names for application / collaboration sessions may be generated in other ways without departing from the scope of the claimed technical features.

As further described in FIG. 45, the status of the application delivered from the originating client is serialized to a format suitable for transmission over the network at block 4510. Those skilled in the art will appreciate that serializing one or more objects includes translating the representation of these objects from internal memory into a text oriented format such as byte or XML. In particular, each object implemented by the present invention that affects the state of the application is recognized so that it can be serialized to XML. By way of example, the state information serialized at block 4510 may include the conditions of an application's user interface component (eg, reduced, expanded, selected, etc.), dynamically loaded resources, coordinates occupied by the application on a visual display. May contain variables describing the location.

At block 4512 of the collaboration start routine 4500, an initialization message is sent from the originating client to the destination client. As discussed above, at block 4512, messaging services provided by server-side data center 4402 may be used to communicate the initialization message with the appropriate destination client. As an example, the initialization message that starts the collaboration session includes an application package XML document corresponding to the delivered application. At block 4512, a serialized representation of the application state (generated at block 4510) is included in the application package XML document or provided independently for transmission to the destination client.

At block 4514 of the collaboration start routine 4500, the shared application is built and begins execution at the destination client. When an initialization message is received, the data type identifier of the destination client is used to identify the received application package and to initiate the opening of the received application package. In this regard, the application start routine 1000 described with reference to FIG. 10 opens an application package and builds an application of a destination client. However, as an example, representations of objects that include an application state in the internal memory are de-serialized based on state information provided in the received initialization message. As a result, the application state is regenerated when serialized at the originating client and rendered by the XML virtual machine on the destination client. The collaboration start routine 4500 then proceeds to block 4516 for termination.

Once the collaboration start routine 4500 is complete, changes affecting the state of the application on one client can be synchronized and reflected to other clients participating in the collaboration session. While the application is being shared, each client participating in the collaboration session runs the application using an XML virtual machine and a local processor. Data bound to the application and application state is synchronized and interpreted by each client using the state manager and the collaboration manager independently. As a result, the processing loaded for application execution is distributed among each client participating in the collaboration session.

Referring to FIG. 46, state synchronization routine 4600 synchronizes the state of an application through clients participating in a collaboration session to be described. As described in FIG. 46, state synchronization routine 4600 begins at block 4602 with an application that includes a collaboration session that has caused a state change. Once the collaboration session is started, the user can continue to access all the functionality of the application. As events occur that affect the state of the application, XML formatted messages describing the state change may be propagated from the originating client to one or more destination clients. Traditionally, events that affect the state of the application can be generated by the user by providing input or by interacting with the application. In particular, the data is updated to include the data bound to the applications included in the unsynchronized collaboration session to take advantage of the state manager's functionality. Instead, similar to the chat application described above, documents bound to the application included in the collaboration session are actively shared using the transaction manager and server-side transaction coordinator of each client, as described above. Accordingly, the state change that occurred at block 4602 does not correspond to a data update that affects application data binding.

As further described in FIG. 46, the state change in the application is implemented locally at the client where the state change started at block 4604. After describing aspects of an XML virtual machine that implements application state changes, a description of aspects of the present invention is not provided herein. As mentioned previously, state manager 4412 provides functionality for monitoring the state of each user interface component of the system. As an example, each change in state of an application is ultimately communicated from the appropriate user interface component to the state manager 4412.

Next, at block 4606, it is determined whether the application in which the state change occurred is in a collaboration mode. As an example, an application is placed in a collaboration mode when a collaboration session involving an application is started. In this regard, a flag or variable is associated with the application to indicate whether the application is currently in collaboration mode. If the value of the variable indicates that the application is not in current collaboration mode, then the test result performed at block 4606 is “no” and state synchronization routine 4600 proceeds to block 4616 for termination. Conversely, if the application is in collaborative mode, the result of the test performed at block 4606 is “yes” and the state synchronization routine 4600 proceeds to block 4608.

At block 4608 of state synchronization routine 4600, collaboration manager 4410 is called to propagate the state change that occurred at block 4602 to one or more destination clients. As an example, the functionality implemented in state manager 4412 identifies an application where a state change has occurred and determines whether the application is in a collaboration mode. If the application is in collaboration mode, collaboration manager 4410 is used to synchronize state changes of each client participating in the collaboration session. In this regard, state manager 4412 may provide collaboration manager 4412 including an application name and a semantic description of the state change in the call issued at block 4608.

At block 4610 of state synchronization routine 4600, an update message describing the state change is sent from the originating client where the state change occurred to one or more destination clients. In one example, the update message is used to synchronize the state of an application executed on other clients. By delivering an update message that utilizes the services provided by server-side data center 4402, the application state can be shared by clients participating in the collaboration session. In particular, the state change semantically described in the update message may be interpreted by the collaboration manager and the state manager on the destination client to replicate the state change made at the originating client.

At block 4614 of the collaboration start routine 4614, the state change is implemented at the destination client that participated in the collaboration session. When an update message describing the state change is received, the update message is routed to the state manager 4412 of the destination client. As an example, the setProperty () function is encoded in an object provided by the XML virtual machine to implement application state changes. As arguments are received in the update message, state manager 4412 can call the setProperty () function directly from the appropriate application component. In this regard, the data received from the originating client where the state change occurred is provided with a call to the setProperty () function to implement the state change on the destination client. Thereafter, if a state change is implemented in each client participating in the collaboration session, the state synchronization routine 4600 proceeds to block 4616, which terminates.

Referring to FIG. 47, an exemplary screen display 4700 of an application that can be used to illustrate aspects of the present invention is described. In this example, an instance of the “presentation viewer” application is shared with multiple clients participating in a collaboration session. As illustrated in FIG. 47, an application view is rendered within a presentation viewer dialog 4701 including a plurality of user interface components including a navigation component 4702, a slide display component 4704, and a node component 4706. .

Aspects of the present invention for performing gesture-based collaboration are implemented in a number of embodiments. As mentioned previously, when a user performs a “drag-and-drop” that moves the presentation viewer dialog 4701 outside the boundaries of the screen display 4700, a collaboration session may be initiated. In this example, the same presentation viewer dialog 4701 is shared on the "virtual desktop". In particular, when a “drag-and-drop” operation is performed, any portion of the presentation viewer dialog 4701 that has been moved out of the bounds of the screen display 4700 is rendered at the destination client. In turn, the change in the location of the presentation viewer dialog 4701 that occurs at the destination client affects the location of the dialog 4701 of the starting client, as each user interacts with the same virtual desktop. In other words, the location to which the presentation viewer dialog 4701 is assigned is rendered through the screen displays of clients participating in the cooperative session, in particular providing a single virtual desktop through which multiple users interact. In another embodiment, the presentation and location occupied by dialog 4701 is “mirrored” to each client participating in the collaboration session. As mentioned previously, when a recognized object is associated with a particular user name for gestures to understand, a collaboration session can be started. For example, note component 4706 described in FIG. 47 includes comments received from multiple users regarding a particular slide of the presentation. The received comment is associated with the usernames 4708 and 4710 of the user who provided the comment. For example, when slide 4712 described in slide display component 4704 is “dropped” at username 4708, a collaboration session may begin. In this and other instances, the application can be reflected to each user sharing the same application view that is not rendered through the boundaries of the screen display. Instead, the location occupied by the presentation viewer dialog 4701 is replicated to each client along with state changes and data updates.

In another embodiment, the application included in the collaboration session is “cloned” to each client. When this kind of collaboration session begins, each client is provided with a distinct and separate view of the application. Regardless of whether the application view is shared or replicated, data updates and state synchronizations are immediately propagated to clients involved in the collaboration session. However, when an application is replicated, re-positioning of the dialog is not propagated to other clients involved in the collaboration session. Instead, state changes and data updates are propagated between clients. Changes in the visual representation of the application that do not represent state changes or data updates, such as dialog re-positioning, are not propagated. This embodiment allows users to have a collaborative experience that can interact with the application in various ways without affecting the view of other clients. For example, a user can initiate a collaboration session that shares the experience of interacting with a web browser. When a user navigates a particular web site, the event of loading the web page is propagated between the clients, including the collaboration session. However, when an application is duplicated in an embodiment, other interactions that affect the application view are not propagated. For example, if a user “scrolls” to access content outside the visual display represented by a web browser, this event does not generate a state change or data update, but instead provides each user with the same Internet navigation experience. You are allowed to access the desired content independently. This is one example of methods for various embodiments of the gesture-based collaboration described to provide a more adaptive platform for the execution of applications.

While the illustrative embodiments have been described and described, it can be understood that various changes can be made without departing from the spirit and scope of the invention.

Claims (4)

A method for actively sharing an application that can be executed by both a source computing device and a destination computing device, the method comprising:
Initiating a collaboration session between the source computing device and the destination computing device;
Communicating the status of the running application from the source computing device to the destination computing device;
Providing the destination computing device with permission to access the resources used by the application including data bound to the running application;
Building the application on the destination computing device; And
Propagating and interpreting a description of the state change to each computing device participating in the collaboration session in response to the occurrence of the state change in the application.
The method according to claim 1,
Communicating the state of the running application from the origin computing device,
Identifying the data currently bound to the application and the resources used by the application.
The method according to claim 1,
Delivering the state of the running application,
And dynamically delivering application resources to the destination computing device without requiring an application previously installed on the destination computing device.
Methods for actively sharing application execution on other computing devices described and described herein.

Images