A look into the world
Figure 27 - The CSCW spatial and temporal quadrants
Download 9.4 Mb.
|
- Navigate this page:
- Internet and the World Wide Web.
- The need for enabling technologies for CSCW
- Supporting Collaboration within Widely-distributed Work-groups
- The Web as enabling technology for CSCW
- Developing Web-based CSCW applications
- Pure centralised architecture
- No guaranteed `Quality of Service
- Extending through CGI
- Customising/building a server
- Customising/building a client
- Providing a Web interface
- Experiences and perspectives of the Web as enabling technology for CSCW
- Experiences of developing Web-based CSCW systems
- Broadening the possibilities for CSCW
Figure 27 - The CSCW spatial and temporal quadrants Examples from the various quadrants are: same time, same place: meeting support tools. same time, different place: video conferencing. different time, same place: A design team's shared room containing specialist equipment. different time, different place: email systems. CSCW radically changes the status of the computer. Until now, the computer has been used as a tool to solve problems. With CSCW, the computer/network is a medium: a means to communicate with other human beings, a vector for information rather than a box that stores and crunches data. If we look at the history of technology, new media have been much more difficult to invent, create and operate than new tools. From this perspective, it is not surprising that CSCW has not yet realized its full potential, even in the research community. I hope this report will help readers to better understand the challenges and promises of CSCW and encourage new developments both in research and in industry. CSCW is not recent. Back in the late 1960s, Doug Engelbart created the NLS/Augment system that featured most of the functions that today's systems are trying to implement such as real-time shared editing of outlines, shared annotations of documents, and video-conferencing. The field really emerged in the 1980s and has been growing since then, boosted in the recent years by the explosion of the  Internet and the World Wide Web.
The Web itself is not a very collaborative system: pages can be easily published but it is impossible (or very difficult) to share them, e.g. to know when someone is reading a particular page or when a page has been modified. The range and complexity of the problems to solve and to support cooperative activities is rapidly overwhelming: data sharing, concurrency control, conflict management, access control, performance, reliability, the list goes on. In addition to these technical difficulties, there is another, maybe harder, problem in implementing groupware: people. For a medium to work, there must be an audience that accepts using it. Usability issues have stressed the need to take the users into account when designing, developing and evaluating an interactive software. For groupware, usability issues go beyond the now well-understood (if not always well-applied) methods from psychology and design. They involve social sciences to understand how people work together, how an organization imposes and/or adapts to the work practices of its workers, etc. In many CSCW projects, ethnographic studies have been conducted to better understand the nature of the problem and the possible solutions. A large body of the research work in CSCW is conducted by social scientists, often within multidisciplinary teams. Computer scientists often ignore or look down upon this aspect of CSCW and almost always misunderstand it. User-centered design is essential to ensure that computer scientists solve the right problems in the right way. Traditional software works as soon as it "does the job"; Interactive software works better if it is easy to use rather than if it has more functions; Groupware works only if it is compatible with the work practices of its users. A large part of this section is devoted to the exploration of these problems and the state of the art of their solutions. In fact, CSCW is challenging most of the assumptions that were explicitly or implicitly embodied in the design of our current computer systems. CSCW tools, or groupware, are by nature distributed and interactive. To succeed in the marketplace, they must be safe (authentication), interoperable (from network protocols to operating systems and GUI platforms), fault-tolerant and robust (you don't want to be slowed down or loose your data if another participant in the session uses a slow connection or experiences a crash). The need for enabling technologies for CSCW
Most of the CSCW systems, which have been developed to date, have been constructed in laboratories as research prototypes. This is perhaps not surprising, as CSCW systems place novel requirements on underlying technology such as distributed systems and databases, and many of the mechanisms developed to support multi-user interaction do not address issues of cooperation such as activity awareness and coordination. This has focused much attention on the development of mechanisms to support floor management, user interface `coupling', update propagation and so on, and has resulted in a range of experimental systems tailored to the particular issues being investigated. The proprietary and incompatible architectures on which many are based, the esoteric hardware and software required and the lack of integration with existing application programs and data formats inhibits deployment outside the laboratory and within the intended application domain. It might be argued that this situation is not unduly problematic; issues of system deployment are `implementation concerns' and would be addressed by re-implementation of system prototypes. The lack of system deployment does however pose a serious question to CSCW: if systems built to investigate particular models or mechanisms are never deployed and evaluated in use, how can we determine the effectiveness of these models and mechanisms in supporting cooperative work? A central concern of CSCW is the need for systems which are sensitive to their contexts of use, and a body of empirical data exists to show the problems caused when systems are introduced which do not resonate with existing work practice. When systems do not leave the research laboratory it is difficult to see how the models and mechanisms they propose can be assessed other than from a technical perspective. Recent calls for CSCW systems to be designed so they can be evaluated in use and for a more situated approach to system evaluation reflect this need to migrate CSCW systems out of the laboratory and into the field if we are to eventually provide more effective systems. This migration is far from trivial, as the diversity of machines, operating systems and application software, which characterises the real work domain, is often far removed from the homogeneity of the laboratory. This is particularly true for working groups, which cross departmental or organisational boundaries, where issues of integration and interoperability mean it is extremely unlikely that systems developed as research prototypes can be directly deployed. Adaptation or re-implementation of system prototypes for deployment outside the laboratory is usually beyond the resources of most research projects, suggesting that the issue of system deployment and the attendant problems should not be tackled at the end of the prototype development, but should be a central focus of the system design. Developing CSCW systems that integrate smoothly with systems, an applications and data format already in place in the work domain adds considerably to what is already a complex design task. A number of researchers have pointed to the need for tools to assist with the development of CSCW systems, removing some of the complexity of user interface, application and distributed systems programming which developers currently face. Such `enabling technologies' would ease problems of system development and allow a more evolutionary approach--an approach otherwise prohibited by the investment necessary to create system prototypes and the need to commit to policy decisions at an early stage in a system's design. Work in CSCW is already addressing these issues through development of toolkits or application frameworks with components, which can be instantiated and combined to create groupware systems. Toolkits such as GroupKit are by now relatively mature, and seem to reduce the complexity of CSCW system development in much the same way that user interface toolkits allow rapid development of single-user interfaces. As I have shown, the desire for enabling technologies for CSCW lies not only in easing problems of prototype construction but also facilitating deployment and thereby evaluation of system prototypes in real work domains. As yet, most CSCW toolkits focus primarily on system development and issues of cross-platform deployment, integration with existing applications and so on are secondary. In this regard more than any other the World Wide Web seems to offer potential as an enabling technology for CSCW: Web client programs (browsers) are available for all popular computing platforms and operating systems, providing access to information in a platform independent manner, Browsers offer a simple user interface and consistent information presentation across these platforms, and are themselves extensible through association of external `helper applications', Browsers are already part of the computing environment in an increasing number of organisations, requiring no additional installation or maintenance of software for users to cooperate using the Web, Many organisations have also installed their own Web servers as part of an Internet presence or a corporate Intranet and have familiarity with server maintenance and, in many cases, server extension through programming the server API. As a basis for deployment of CSCW applications in real work domains, the level of acceptance and penetration of Web technology in commercial and academic environments is grounds alone for suggesting that CSCW should pay serious attention to the World Wide Web. Supporting Collaboration within Widely-distributed Work-groups
Most shared Workspace system were conceived as a means of supporting the work of widely-dispersed work- groups, particularly those involved in large research and development projects. Members of such projects may come from a number of organisations, in different countries, yet have a need to share and exchange information and often collaborate over its production. The geographical distribution prohibits frequent face-to-face meetings, and would clearly benefit from computer support for the collaborative aspects of the work. Unfortunately, the lack of common computing infrastructure within the group often prohibits deployment of such technology and causes serious problems for system developers who must pay close attention to issues of heterogeneous machines, networks, and application software. As a consequence of these problems, despite over 10 years of research in the field of CSCW (Computer Supported Cooperative Work), email and ftp remain the state-of-the-art in supporting collaboration within widely-distributed work- groups. Although such tools facilitate information exchange, they provide little support for information sharing, whereby details of users' changes, annotations and so on are made visible and available to all other participants. A conclusion drawn by many is that for more powerful CSCW technologies to flourish, a common infrastructure that addresses problems of integration is required, allowing developers to focus on application details rather than complexities of different system configurations. The W3 is the first real example of such a common infrastructure, offering huge potential to CSCW system developers, through: platform, network and operating system transparency, integration with end-user environments and application programs, a simple and consistent user interface across platforms, an application programmer interface for 'bolt-on' functionality, and ease of deployment facilitating rapid system prototyping. Given this potential, it is unsurprising that a number of W3- based collaboration systems have been developed. We can classify these systems in four broad categories, based on the extent to which they depart from existing W3 standards: Purely W3-based: Such systems use standard W3 clients, comply with HTML and HTTP standards, and only extend server functionality using the CGI interface. Any additional client functionality is provided by helper applications (we do not include client APIs here, such as CCI, as they are not standardised across clients and platforms). An example of such a purely W3- based system is reported in. Customised servers: As 1, but require special-purpose servers, to provide behaviour beyond the possibilities offered by CGI. Such systems still support standard W3 clients and protocols, but the enhancements may reduce the portability of the server itself. InterNotes is an example of such a customised server. Customised clients: As 1 (and sometimes 2), but require particular or modified clients (often to support non-standard HTML tags), or non-standard client APIs, and could not necessarily be used with different platforms or different clients. These systems do however support the HTTP protocol. The Sesame client for Ubique's Virtual Places system is an example. Web-related: Such systems may provide a W3 interface, but support only limited interaction using the HTTP protocol. The Worlds system is an example of this category. In this classification, the degree of W3 compliance decreases from 1 to 4; one might say that a system in Category 1 inherits all the benefits of the W3 listed above, while a system in Category 4 gives the developer a free- hand in choice of protocols, interface toolkits and so on but few of the benefits. A major goal of this work was to produce a useful and usable system--one that could be deployed in the target domain and refined on the basis of actual usage feedback. It therefore means that some set of design goals has to be set as follows: No modification to the HTTP protocol No modifications to HTML, or client customisation other than through Helper applications All server customisation to be performed through the CGI interface The following section describes the current version of the system we developed, and we then return to these three design goals to discuss the system's implementation. The Web as enabling technology for CSCW
``[The Web] was developed to be a pool of human knowledge, which would allow collaborators in remote sites to share their ideas and all aspects of a common project'' (Berners-Lee et al. 1994, page 76). From its inception the Web was intended as a tool to support a richer, more active form of information sharing than is currently the case. Early implementations at CERN allowed the browsing of pages as is common today, but also supported annotation of these pages and addition of links between arbitrary pages, not just from pages on local servers the user can access and edit. Some of these concepts were carried through to early drafts of the standards for Web protocols and architecture which described features such as remote publishing of hypertext pages and check in/out support for locking documents to ensure consistency in a multi-author environment. To date these aspects have largely been sidelined while development of Web browsers, servers and protocols has focused on more `passive' aspects of information browsing. In this section I examine the Web as it currently exists as a platform for developing and deploying CSCW technologies, following a brief overview of the components on which it is based. Developing Web-based CSCW applications
Despite the lack of direct support for collaboration, the current Web architecture does hide some of the complexity of deploying applications in a distributed, heterogeneous environment. The most common method of doing this is by extending a Web server through the CGI with new application functionality or `glue' code to an existing application, presenting the application user interface as a series of HTML pages, which can be displayed by standard Web browsers. With this approach developers can take advantage of the existing base of browsers as client programs for their applications but must accept the constraints of the basic Web architecture and protocols as currently implemented and the limitations of existing Web browsers. These constraints are severe, inhibiting the development and deployment of CSCW applications in a number of areas: Communication: There is no support for server-server, (server initiated) server-client or client-client communication, problematic for applications where the server needs to play an active role (e.g. to notify users of changes to information or maintain information consistency over several servers). One consequence is that applications are now in common use which poll Web servers periodically to check if pages have been updated, allowing users to monitor Web sites of interest (e.g. Netscape's SmartMarks). Users can specify a very small time interval between checks, even for pages which change rarely, leading to huge amounts of unnecessary traffic on the Internet and `hits' on Web servers. Pure centralised architecture: The architecture provides no support for distribution of information or computation between clients and servers or replication across servers. Expensive, powerful and fault-tolerant machines are required to run a Web server if it is to scale to a large number of users. Even simple computations are not performed by the client, for example to check if a user has filled in all the fields of a form, resulting in unnecessary network traffic, server loading and slow feedback times for the user. The lack of support for replication means that disconnected working is not possible. No guaranteed `Quality of Service': The HTTP protocol does not support the specification of guaranteed transmission rates between servers and clients. Data transfer is often `bursty', subject to network and server loading which might vary considerably during a single transmission. This is unsuitable for transmission of (real-time) continuous media like audio and video, and alternative protocols such as RTP, `the Real-Time Protocol', have been proposed for these media types. User interface design: HTML is not a user interface design toolkit, and although mark-up tags are provided for simple form-filling widgets like input fields these do not support features now common in desktop user interfaces such as drag and drop, multiple selection and semantic feedback. Although some browser vendors have introduced new tags to provide features like multiple, independent screen areas (Netscape Frames) they do little to broaden the possibilities for user interface design (and are not supported by all browsers). A fundamental problem here is the lack of server-client notification (see above); it is easy for the interface to become inconsistent with the information on the central server and is only updated when the user reloads the entire page. Some of these limitations are not so much problems with Web components like HTTP and HTML but more with the current implementations of browsers and servers. For example there is no reason why a server could not act as a client and vice versa to allow a form of update propagation and notification. (In fact some servers can send requests as well as handle them, often to act as a `proxy' for routing requests through a firewall.) These limitations do however restrict the kinds of CSCW systems which can be developed as extensions of the Web using the CGI, and suggest that the Web in its current form is largely unsuitable for developing systems which require highly-interactive user interfaces, rapid feedback and `feedthrough' (user interface updates in response to others' interactions) or a high degree of synchronous notification. Of course, extending a Web server through the CGI programming interface is not the only method of deploying a CSCW system on the Web, and more radical approaches can remove some of the constraints of the basic architecture. Based on the extent to which a developer must modify the basic Web components, we can identify the following approaches: Extending through CGI: As described above, where no modifications are required to protocols, browsers or servers. Any additional client functionality is provided through `helper' applications. The BSCW system described in the next section is an example of such a system. Customising/building a server: Building a special-purpose Web server may be necessary to achieve adequate performance or security, or to introduce new functionality such as server-initiated notification. This approach requires deployment of the server software and any other application code, but is sometimes a better method of enabling access to existing applications from the Web in a more flexible and secure manner than CGI. The BASIS WEBserver, which enables Web access to the BASISplus document management system, is a good example of this. Customising/building a client: Building a special-purpose client allows applications other than Web browsers to communicate with Web servers using HTTP, such as the `coordinator' clients developed for the WebFlow distributed workflow system (Grasso et al. 1997). Customising a client may also be necessary to interpret non-standard HTML tags such as those proposed by Vitali and Durand (1995) for version control to support collaborative editing of HTML documents. Custom clients can be used in conjunction with custom servers to provide additional services; as part of their Virtual Places system, the Ubique client can interact with the Virtual Places server to provide synchronous communication and a form of `presence awareness'. Providing a Web interface: Some systems such as Worlds (Fitzpatrick et al. 1995) provide a Web interface but are not designed specifically for deployment on the Web. These applications use other means of providing the user interface, managing data and event distribution and so on, and only limited interaction is possible using a Web browser and HTTP. Using this classification the flexibility for the developer increases from 1 to 4, and many of the problems identified above can be solved by specialising or replacing components such as clients and servers to provide richer mechanisms for the user interface, update propagation and so on. Of course, this level of flexibility is bought at the price of the innovation required from developers to build or integrate these components, and it should be obvious that very soon we may find ourselves back to square one; with a system which cannot be deployed outside the laboratory due to particular hardware and software requirements and a lack of integration with existing user environments. In this case, if our goal is eventual deployment and evaluation in real work domains, there seems little point in using the Web as a platform for CSCW system development. Despite these problems however I would strongly argue that the Web is an `enabling technology for CSCW'. The limitations identified above mean the Web is more suited to asynchronous, centralised applications with no strong requirements for synchronous notification, disconnected working and rich user interfaces. The advantages however--an accepted technology, integrated with existing user environments and extensible through the server API without requiring additional client software on users' machines--indicate that here we have a method of deploying and evaluating basic mechanisms to support collaboration in real work domains. Further, the rapid pace of development in Web technologies suggests that many proprietary and experimental features, which address some of the current limitations, could become standards in the future. Of course much depends on the willingness of the main browser vendors (currently Netscape and Microsoft) to agree on and implement these features, but this does not seem to have been a problem to date. As Web technology matures some of the current problems with CSCW development on the Web should be solved. Experiences and perspectives of the Web as enabling technology for CSCW
In this section I am concerned primarily with the Web as a potential enabling technology for CSCW systems, rather than possibilities for enhancing the Web itself with mechanisms to make it more `collaborative'. I therefore focus my discussion on the role of the Web as a vehicle for developing and deploying CSCW systems, instead of a target of CSCW research in its own right, and thus orient more to the utility of current and future Web standards for CSCW systems rather than possible modifications to these standards as informed by CSCW research. This last however is clearly an area where CSCW and the Web have much to say to each other; for example, the phenomenon that the Web is currently a `lonely place' is an argument put forward by Lea et al. (1997) for their work on Virtual Societies, and the goal of adding group `awareness' mechanisms to augment the Web is receiving increasing attention from the CSCW community (see for example Greenberg and Roseman 1996, Palfreyman and Rodden 1996). The topic of awareness is only one of several issues, which might be included in a research agenda for CSCW with respect to augmenting the basic Web architecture, protocols and technologies. I have taken the position that for CSCW the role of an enabling technology is twofold, easing problems of both development and deployment of CSCW systems in real-world domains, and that deployment is best achieved when systems integrate smoothly with existing Web technologies. I now discuss the possibilities and problems of developing CSCW systems on the Web, before reviewing recent developments, which might address these problems and broaden the range of CSCW systems, which can be supported. Experiences of developing Web-based CSCW systems
The current standards for Web components like HTML and HTTP reflect the emphasis to date on the Web as a tool for information browsing. This allows information providers to design and retain control of the form and content of their information and `publish' it via a Web server. Consumers can then access the information by sending requests via their Web browsers. The CGI server programming interface allows extension of the Web within this `provider-consumer' framework, so that servers can generate responses on-the-fly as well as serve static Web pages stored in files on the server file system. Our experiences with most collaborative system suggest that, as a tool for application development, it is straightforward to extend the Web with application functionality or interface to an existing application. The method of passing request details through the CGI programming interface is simple and allows developers to write extension programs in most programming languages, with no need to link extension code with the server. Extension programs must generate and return HTML, which again is straightforward. In combination with a high-level, interpreted programming language such as Python, this arrangement allows extremely rapid prototyping and testing using a standard Web client and server. The CGI approach does however inherit all the problems of the request-response model of the Web. One of these is the feedback delay caused by the round-trip to the server to service every user interaction. When requesting documents or even HTML pages this delay may be acceptable, but for simple requests, especially those that change only the state of the interface, this delay is a problem. For example, with the BSCW system it is possible for users to fold in/out the object action and description lines using the `A' and `D' buttons, and with the adjacent checkbox buttons select all/none of the objects in a folder listing. Using these features requires a request to the server to generate a modified HTML page, and when interacting via the Internet (as do most of the users of our public server) network delays represent a much larger component of the total time to service the request than processing time. In designing a user interface for a Web-based application, developers must take care to reduce the number of required trips to the server, possibly by allowing the user to `batch' requests at the client (using multiple HTML forms for example). At the server side the simplicity of the CGI approach can also be problematic. The execution of extension programs in separate processes which are passed details of the request may allow rapid development, but gives the developer no chance to modify server behaviour or request information which is not passed explicitly through the CGI. Where the default behaviour is adequate, as is the case for the user authentication features used directly by BSCW for example, there are no problems. Where features are inadequate for an application's needs the developer cannot modify these but must either re-implement them using the CGI or build a custom HTTP server (Trevor et al. 1996). The Web is best suited as a development platform for applications which do not need to step outside the information provider-consumer model, currently enshrined in existing standards and browser and server implementations. When this is required, it is often necessary to provide additional components at the server or client (in the form of helper applications). The latter removes one of the main advantages of the Web, which is the ability to deploy systems without requiring development of client programs that run across platforms or installation of additional software by users. For BSCW, the need to upload documents to the server has required considerable effort to produce versions of the (very simple) helper, which operate on PC, Macintosh and Unix machines. For this and other aspects such as synchronous notification, information replication and so on the basic Web standards and components offer no support and developers must provide their own solutions. Much of the work in the Web standards community is focusing on refinement of protocols, client and server architectures to improve the speed and reliability with which requests can be handled, and not on providing more flexible and powerful components for application development. This emphasis is not surprising; the growth of the Web has been so rapid that aspects of the HTTP protocol in particular must urgently be re-designed to ensure the Web architecture can continue to scale to millions of users worldwide. However, this growth has also led to demand from users and third-party vendors for extensions to Web components to allow richer support for different media types, user interfaces and so on. To meet this demand, server and browser vendors have proposed a number of mechanisms and built support for these in their products. There is some evidence that this practice is key in the continuing development of the Web. An example of this is the support for HTML page editing and remote publishing, identified as an area requiring support by a number of vendors including Netscape (with the Navigator Gold browser), Microsoft (with FrontPage) and GNN's GNNPress. Although the solutions offered are currently incompatible, all have a need for uploading documents to a Web server and this has prompted efforts to agree a standard method for doing this. The World Wide Web Consortium (W3C) has recently established a working group on "Distributed Authoring and Versioning on the World Wide Web" to examine requirements and work towards specifications to support this activity. Similarly, the need for richer Web pages has led to tools like Java and JavaScript being supported by the major browser vendors and becoming de-facto standards. Where relevant, these de-facto standards have also filtered into the documented standards process, as is the case with some of the proprietary extensions to HTML now part of the latest proposed standard, HTML 3.2. Broadening the possibilities for CSCW
As Internet technologies continue to penetrate and impact upon marketing, finance, publishing, organisational IT and so on, the demand for extension and innovation will increase. The growth of the corporate Intranet, for example, raises requirements of information replication, workflow services and the like, while commerce applications require much higher levels of security and privacy than are currently supported. Although many vendors will seek to provide proprietary solutions to these requirements, and thus lock corporate customers into particular technological solutions, it is also clear that technologies are emerging which have the potential to broaden the possibilities for third-parties to customise Web components and develop new extensions in a more generic fashion. The problems of the CGI approach to extending an existing Web server are well known, and vendors of Web server technology are seeking to provide more flexible solutions for developers. For example, in designing the API for the Apache server (currently the most well-deployed Web server on the Internet), the developers sought to allow ``third-party developers to easily change aspects of the server functionality which you can't easily access from CGI'' (Thau 1996, page 1113). Similar developments in browser programming interfaces such as Netscape's `Plug-in' development kit and Microsoft's `ActiveX' environment are intended to extend the capabilities of standard Web browsers to handle new media types directly, embed Web browsers in other applications and more. Such advances in client and server programming interfaces allow development of much richer CSCW systems, better integrated with desktop environments than is possible with basic Web components. In the main however these developments are specialised to particular browsers or servers or operate only on particular platforms, and do not offer the same advantages as the basic components for cross-platform deployment of CSCW systems. Although some vendors have announced support for others' programming interfaces, it remains to be seen how this will work in practice as they (particularly browser vendors) seek to differentiate their products on the basis of the richness of features supported. An approach, which is independent of particular client and server programming interfaces, seems to offer more potential in this regard. One area receiving much attention is that of `mobile code' where, in addition to data in HTML or other formats, a browser might download small application programs or `applets' which are executed on the local machine, taking input and displaying output via the Web browser. This should remove many of the constraints on the application developer: applets can be designed which provide much richer user interfaces than are possible with HTML; computation can be moved to the client, for example to check for valid input data and thus reduce network traffic, server loading and feedback lags; applets supporting special protocols can be developed which handle different media types and so on. Although there are many problems to be overcome, most notably security concerns when code downloaded over the Internet is executed on the user's machine, significant progress has been made in this area. The latest Web browsers now provide support for applets written in Sun’s Java programming language from Netscape, Microsoft and IBM. For tasks requiring less power than a full programming language, scripting tools like Netscape's JavaScript follow similar principles but are less ambitious, allowing HTML pages to be extended with code fragments to pass responsibility for simple computations from the server to the client. I see these developments as broadening the role of the Web as an enabling technology for Directory: files files -> Answer True False 2 points Question 2 files -> Integer programming and game theory files -> 4 Integer Programming files -> Bpa vehicle Window Repair Scenario #1 task: Procure vehicle window relacement. Objective files -> Pop Warner History files -> North Carolina Inclusion Initiative Mapping Where Children with ieps are Being Served Purpose files -> Fall 2013 Spring 2014 Program Data: Standard 1 Exhibit 4d files -> Hanban – asia society confucius classrooms network 2010 request for proposal files -> Northern England’s set-jetting locations Download 9.4 Mb. Share with your friends:
|