The World Wide Shell based on The Object-Stacking Model
Yasushi Shinjo Institute of Information Sciences and Electronics University of Tsukuba Tsukuba, Ibaraki 305, Japan Phone: +81 298-53-6562, Fax: +81 298-53-5206 E-Mail:
[email protected] URL: http://www.is.tsukuba.ac.jp/~ yas/ Object-stacking is a model for structuring object-based systems. The main feature of the object-stacking model is that layers of objects with a uniform interface are constructed, and the functions of these objects are integrated. In object-stacking, ltering functions are converted into objects. By implementing object-stacking in the World Wide Web, several ltering functions scattered all over the world can be integrated into a single web resource. In object-stacking on the World Wide Web, the super uous recursive stacking problem should be solved. This paper shows the solution of the problem by using redirection HTTP objects. Abstract.
1 Introduction On the Internet, a great amount of information and knowledge have been accumulated and become available as the resources which can be accessed on the World Wide Web (WWW) (Figure 1). To use these resources e ectively, the following are demanded: 1. Tools for creating new resources from existing ones by processing. 2. Mechanisms for integrating those tools. 3. Tools for maintaining consistency among multiple views of a single resource. On UNIX, many useful tools are available as lter commands. Multiple lter commands can be integrated into a single command by using pipes and a shell. To realize such integration at the le system level, I have proposed the objectstacking model [9]. Object-stacking is a model for structuring object-based systems. The main feature of object-stacking is that layers of objects with a uniform interface are constructed, and the functions of these objects are integrated. I have presented the implementation method of the object-stacking model on WWW [8]. By using object-stacking on WWW, new resources can be generated from existing resources on the Internet (Figure 1). Furthermore, it is easy to maintain consistency among several views of a single resource. To implement object-stacking on WWW, I have proposed three techniques: demand stacking, virtual stackable objects, and pointer swizzling [8].
The Internet
: Resource : Filter
Fig. 1.
: Integration : Hyper reference
Resources and lters on the Internet
In object-stacking on WWW, each stackable object provides a simple lter function, such as image conversion or code translation. By stacking several objects scattered all over the world, their lter functions are integrated and used together. In this integration, the interpreter of URLs acts as a shell which designates the con guration and the order of lters. In object-stacking on WWW, the super uous recursive stacking problem should be solved. If an object is a stackable HTML object, and it includes a URL to a following HTML object, the following HTML object becomes a stackable HTML object as well. This automatic (recursive) stacking is usually useful, but sometimes it is not desired. In this paper, I show the solution of the problem by using redirection HTTP objects. A redirection HTTP object is described by the same form of URL as that for stackable HTTP objects, and sends redirection messages to clients. A redirection message created by a redirection object is propagated to the original client, and the redirection message forces the client to access the desired object directly. As a result, unnecessary stacked objects are poped up. In object-stacking on WWW, each provider of a ltering function has to develop a server of stackable objects. Therefore, it is important to support the implementation of stackable servers (the servers of stackable objects). In this paper, I present system support for implementing the stackable servers on WWW which provide ltering functions. By using this support, the work of each developer is to write a module which matches one of three well-de ned interfaces.
2 Object-stacking on WWW Object-stacking is a model for structuring object-based systems. The main feature of object-stacking is that layers of objects with a uniform interface are constructed, and the functions of these objects are integrated. In object-stacking,
Client 1 (Mosaic)
Client 2 (Mosaic)
(thru) c1
c2
kanji b1 to romaji
b2
a1
a2
index.html
convert -scale 0.5x0.5
(thru)
title.gif Interface : An object (resource) : Object ID (URL)
Fig. 2.
Integrating the functions of objects by stacking in WWW.
objects are classi ed into two types: bottom objects and stackable objects. Each bottom object provides a primitive function, such as data storage or data generation. Each stackable object provides a high-level function, such as ltering, indirection, caching, masking, or grouping. These functions are integrated by connecting several stackable objects and a bottom object. To implement object-stacking, the concept of objects, a uniform interface and object-ids are essential. In WWW, the resources which are transferred via HTTP can be regarded as objects [8]. The uniform interface (the set of procedures) includes the GET request of HTTP. URLs are object-ids. An HTTP object is the general term for an object which is transferred via HTTP. An HTML object is a text object which is described in HTML.
2.1 Filtering by Stackable HTTP Objects A stackable HTTP object is an stackable object which is managed by an HTTP server, and provides a high-level function such as ltering, masking, or caching. Figure 2 shows two stacks of HTTP objects. The concrete objects in Figure 2 provide the following functions, respectively: (a1, a2) These objects store data. (b1, b2) These objects translate kanji into romaji for text objects, and do nothing for the other types of objects. Romaji is an alphabetical description of Japanese pronunciation. It is very useful for people in the other countries to
Fig. 3.
Formatted HTTP objects (original and ltered)
view WWW pages in Japanese kanji (Chinese characters) without special equipments for Japanese. (c1, c2) These objects scale down the sizes for image objects, and do nothing for the other types of objects. Since these objects reduce the size of image objects, the created smaller views are useful for the users who access through a slow communication line. These functions are integrated into the top objects, Object c1 and c2 in Figure 2. That is, a romaji text object and a small image object are created. Figure 3 shows the e ects of the stackable objects. On the left of Figure 3, a large image and kanji characters are displayed. These correspond to Object a1 and a2 in Figure 2. On the right of Figure 3, a small image and romaji (alphabet characters) are displayed. These correspond to Object c1 and c2 in Figure 2. I have implemented several stackable HTTP objects. The following is a list of useful stackable HTTP objects: 1. Image conversion object. Image format conversion, scaling (Figure 3) and changing the number of colors. 2. Speech synthesis object. Text-to-speech translation. 3. KAKASI object. Kanji-to-romaji translation (Figure 3), showing the readings of kanji characters, etc. This translation is done by the KAKASI command [10]. 4. M4 macro object. The m4 macro language processor of UNIX. 5. Encryption object and decryption object. 6. Sed object. The sed command of UNIX.
7. Kanji lter object. Kanji code translation. 8. Generic lter object. Any lter command in UNIX can be converted into a stackable HTTP object. 9. Sound conversion object. 10. Automatic annotation objects. Annotations by speech or references to dictionaries are created.
2.2 URLs for Stackable HTTP Objects Each stackable HTTP object is identi ed by the following URL form: http://host1:port1/options1!lower-url1
The server of this object is waiting for requests on host1 at port1. In this URL, the string "options1" determines the behavior of each object in the server. The sign '!' is the delimiter between the option part and the URL of the lower object. The string "lower-url1" is also a URL which starts with "http://". In Figure 2, for example, Object c1, b1, and a1 are identi ed by the following URLs, respectively: (c1) http://hostC:portC/-geometry+50%25!\ http://hostB:portB/-Ha+-Ka+-Ja+-s!\ http://hostA:portA/index.html (b1) http://hostB:portB/-Ha+-Ka+-Ja+-s!\ http://hostA:portA/index.html (a1) http://hostA:portA/index.html
2.3 Con guration of stackable objects Supporting con guration of stackable objects is important. First, to nd out an objective lter on the Internet is as dicult as to nd out an objective regular resource on the Internet. Therefore, search engines and directory services are demanded for stackable lter objects. Second, for each stackable object, some methods to describe options are required. A possible method is to generate URLs by a regular CGI mechanism. For example, Image Machine provides Internet users with the function of image conversion in the ImageMagic package [4] [5]. In Image Machine, a user speci es a URL of source data and complex conversion options through CGI, and gets the converted result in his/her WWW browser. Note that Image Machine is not stackable. The image conversion object described in Section 2.1 also uses the same image conversion program in ImageMagic. In Image Machine, the URLs of conversion results are temporary, and they are expired. In my image conversion object, on the other hand, the URLs of the stackable objects are persistent if their lower objects are persistent.
2.4
Demand Stacking and Virtual Stackable Objects
Unlike stackable le objects [9], stackable HTTP objects are created on demand [8]. Demand stacking means that stacking is done on demand by a client. We call a stackable object created on demand as a virtual stackable object. For example, suppose that a client wants to get the contents of Object c1. The URL of Object c1 is as follows: http://hostC:portC/-geometry+50%25!http://hostB:portB/-Ha+-Ka+-Ja+-s!\ http://hostA:portA/index.html
The client sends the following request in HTTP to Server C on hostC at portC: GET /-geometry+50%25!http://hostB:portB/-Ha+-Ka+-Ja+-s!\ http://hostA:portA/index.html HTTP/1.0
On receiving this request, Server C creates a virtual stackable object (c1). The server analyzes the URL and extracts the option and the URL of the lower object (Object b1). To get the content of Objet b1, Server C sends the following request to Server B on hostB at portB: GET /-Ha+-Ka+-Ja+-s!http://hostA:portA/index.html HTTP/1.0
Similarly, Server B creates a virtual stackable object (b1), and sends the following request to Server A on hostA at portA: GET /index.html HTTP/1.0
On receiving this request, Server A opens the le index.html, and returns the contents of the le to Server B. Server B performs the corresponding lter processing on the contents, and returns the ltered results to Server C. Server C also performs the corresponding lter processing, and returns the ltered results to the client.
2.5 Pointer Swizzling Unlike le systems, HTML objects in WWW include references (URLs) to other objects. To implement object-stacking and server-stacking, these references should be rewritten consistently. I call this rewriting pointer swizzling [8]. This term stands for pointer swizzling in object-oriented databases and operating systems [2] [11]. In stacking HTML objects, pointer swizzling is needed. Let us consider the example in Figure 4. In Figure 4, there are three bottom objects, Object a1,a2,a3. On those three objects, Object b1, b2, b3 are stacked, respectively. Object a1 includes the reference to Object a2. In other words, Object a1 includes the URL of Object a2 ("http://hostA:portA/a2.html"). This URL is written in HTML as follows:
Document 2 is here.
b2
b1
swizzle
b3 swizzle
a1
a2
a3
a1.html
a2.html
a3.html
Fig. 4.
Pointer swizzling
In Object b1, this reference (URL) should be rewritten to the URL of Object b2 ("http://hostB:portB/!http://hostA:portA/a2.html"). This URL is written in HTML as follows:
Document 2 is here.
The following is the URL rewriting rule in pointer swizzling in WWW: 1. For a URL in the full form, the next pre x is attached: "/options!" 2. For a URL in the partial form, the next pre x is attached: "options!http://hostL:portL/dirL/" "options" is the option string which is speci ed in the request URL in HTTP. "hostL" and "portL" are the host name and the port number of the server of the lower object of the target virtual stackable object, respectively. "dirL" is the directory name part of the URL of the lower object.
3 Super uous Recursive Stacking and Redirection HTTP Objects 3.1 The Problem of Super uous Recursive Stacking By the e ect of pointer swizzling, stackable HTTP objects are created recursively. This automatic creation of stackable object is called recursive stacking.
Usually, recursive stacking is useful and necessary. This is because a group of resources can be ltered simultaneously by starting from a single URL. In Figure 4, there three bottom objects (a1,a2,a3). On Object a1, Object b1 is stacked. By pointer swizzling, stackable objects b2 and b3 are created automatically. Recursive stacking is desired to be disabled in the following situations: 1. A hyper reference (HREF) is embedded to jump into a related page, and the related page is not desired to be ltered. For example, if Object a3 in Figure 4 is a such related page, the URL of Object a3 in Object b2 should be preserved. 2. Some lters may con ict one another. Figure 5(a) illustrates con icts of lters. In Figure 5, Object a1 and a2 are regular (bottom) HTML objects managed by a regular HTTP server. Object a1 is a home page, and Object a1 is accessed rst by many users. Object a1 contains three hyper references to Object a2, Object b2, and Object c2, as follows: (Object
- Filter-C.
"B" and "C" are simpli ed notation of stackable HTTP servers. They are "http://hostB:portB/" and "http://hostC:portC/", respectively in full notation. Object a2 is a non- ltered original view. Object b2 and Object c2 are ltered views. The lower object of Object b2 and Object c2 is Object a2. Suppose that Object a2 contains the hyper reference to Object a1, as follows: (Object a2) Back to Home Page. .
By pointer swizzling, the following references to virtual stackable HTTP objects are created automatically. (Object - Filter-C.
By these URLs, two new virtual stackable objects, Object c3 and c4 are created. The URL of Object c4 is "C!C!http://hostA/portA/a2.html", and the lower object of Object c4 is Object c2. The lower object of Object c2 is Object a2. Therefore, in Object c4, Filter C is performed twice. In some lters, such as translation of natural languages, repeated ltering has no meaning.
Object c3 ("C!B!http://hostA/portA/a2.html") contains the results of two di erent lters: Filter B and Filter C. These results may have some meanings, but often con ict with the menu. From the menu, Object c3 is expected to be the results of Filter B alone. Some solutions to the problem of super uous recursive stacking are as follows: 1. To suppress pointer swizzling for the objects on the other sites. In this method, objects scattered all over the world cannot be integrated. 2. To introduce a directive which suppresses pointer swizzling. In this method, the directive may cause trouble if bottom non- ltered objects are accessed directly. I show another solution which uses redirection HTTP objects.
3.2 Redirection HTTP Objects A redirection HTTP object is an HTTP object that does not send regular reply
messages but sends redirection messages de ned in HTTP to clients. A redirection HTTP object is not a stackable object. A redirection HTTP object takes no lower object. However, the URL of a redirection HTTP object has the same form as that of a stackable HTTP object. The following is an example of a URL of a redirection HTTP object (named Object r1): http://hostR:portR/!http://host1:port1/dir1/file1
A redirection HTTP object is a virtual HTTP object, and it is created on demand by the corresponding URL. In the above example, the redirection HTTP object (Object r1) sends the following reply message to clients: HTTP/1.0 301 HTTP Redirection (Moved Permanently). URI: Location: http://host1:port1/dir1/file1 X-Redirection: 1 Propagate
If a regular client receives this message, the regular client resends the request to the server on host1 at port1. On the other hand, If a stackable HTTP object receives this message, the stackable HTTP object nds the "X-Redirection" line, and does not resend the request. But, the stackable HTTP object propagates this reply message to the client of the stackable HTTP object. If the client is also another stackable HTTP object, then it also propagates this reply message to its client. Therefore, this reply message is interpreted by the regular client.
3.3 The Solution of the Problem of Super uous Recursive Stacking By using redirection objects, the problem of super uous recursive stacking is solved. For example, consider the following HTML description:
Client 1 (browser)
c3
c4
b2
c1
c2
a1
a2
(a) Repeated filtering by recursive stacking.
Client 1 (browser)
b2
c1
a1
a2
c2
(b) Suppression of superfluous recursive stacking by effective references.
Interface : An object (resource)
: regular hyper reference : reference to lower object : effective reference by redirection HTTP object
a1, a2 : Objects of Server A, regular bottom HTTP objects b2 : An object of Server B, stackable filter HTTP objects c1,c2,c3,c4: Objects of Server C, stackable filter HTTP objects
Fig. 5.
Recursive stacking and e ective references
"R" is the simpli ed notation of the redirection HTTP server. The rst item causes recursive stacking. The second item suppresses recursive stacking. We call a reference created by the redirection HTTP server as an e ective reference.
The following description is an example of a home page which provides multiple views from a single tree of resources:
This description corresponds Object a1 in Figure 5(b). This gure illustrates that Object a1 and its upper object (Object c1) e ectively refers Object a2, b2, and c2. This page is enough to be changed to contain "R". The following pages (http://hostA:portA/a2.html and its following pages) are not needed to be modi ed.
4 Support for Implementing Stackable HTTP Objects In object-stacking on WWW, each provider of a ltering function has to develop a server of stackable objects. Therefore, it is important to support the implementation the servers of stackable HTTP objects. In this section, I describe system support for implementing the servers of stackable HTTP objects. Each developer of a server of stackable HTTP objects can make use of the following three interface to describe a lter: 1. The procedure interface. 2. The command interface. 3. The RPC interface. By using this support, the work of each developer of a server is to write a module which matches one of these well-de ned interfaces.
4.1 The Structure of a Stackable HTTP Server with Lightweight Processes As similar to stackable le servers [9], stackable HTTP server consists of lightweight processes (threads). There is a request acceptance lightweight process which waits for requests from clients via TCP/IP. For each request, a session lightweight process is created. This session lightweight process handles a virtual stackable object, as follows: 1. It examines the request line of HTTP, and extracts options and the URL of the lower object. 2. It sends a GET request to the lower object. 3. It examines the type (the "Content-Type:" line) of the response message from the lower object, and sends the response headers to clients. 4. It performs the corresponding lter operations on the contents of the response message. 5. It sends the response body ( ltered contents) to the client. Other lightweight processes are created according to parallelism in processing.
4.2 The Procedure Interface In this level, a developer of a stackable HTTP server can make use of a skeleton of a stackable HTTP server. By using this skeleton, the work of the developer is to de ne the following four procedures: class filter { filter( char *options ); ~filter(); int convert( char *from, int *from_lenp, char *to, int *from_lenp ); int flush( char *to, int *from_lenp ); };
I use the syntax of the C++ language. The procedure convert() has to perform a lter operation on the input bu er speci ed by from and *from lenp, and write the ltered results into the output bu er speci ed by to and *to lenp. In this procedure, some intermediate states can be stored in instance variables in C++. The procedure flush() has to clean up intermediate states and write the ltered results into the output bu er. The constructor has to create a userde ned structure from given options which are passed from a client (Section 2.4). The destructor has to deallocate the user-de ned structure.
4.3 The Command Interface In this level, a developer of a stackable HTTP server can make use of another skeleton of a stackable HTTP server that invokes an external lter program. With this skeleton, each developer have to write some procedures which examine options to the external lter program to keep security. Every time the server receives a request, the server creates a process of the external program. The server process and the external process are connected by two streams (pipes). In the server process, two lightweight processes (threads) carry out the request. One is created by the session lightweight process for receiving the data from the lower objects and for writing the received data to the external lter program. The other is the session lightweight process itself. This lightweight process reads the ltered data from the external program, and sends the ltered data to the client.
4.4 The RPC interface At the command level described in Section 4.3, the process of the stackable HTTP server and the process of the external lter program are connected by pipes. At this level, a server process and an external lter program are connected by RPC (Remote Procedure Call). At the command level, every time a request arrives, a new process is created. At the RPC level, there is no overhead of process creation because an RPC server is resident in memory. The interface of the RPC server is similar
to that of the procedure interface described in Section 4.2. An exception is that the RPC interface contains the cookie parameter to store intermediate states of ltering. As an RPC system, I am using SunRPC. I have modi ed SunRPC to be multithreaded, changed interfaces of some functions, and added some stubs.
5 Performance I measured the performance of stackable kakasi objects, described in Section 2.1. Experimental results are shown in Figure 6(a). I measured the performance of the following stackable kakasi HTTP server: 1. Filtering is implemented by the procedure (Section 4.2). 2. Filtering is implemented by the external kakasi command (Section 4.3). 3. Filtering is implemented by an RPC server (Section 4.4). The following options are given to the servers: -Ha -Ka -Ja -Ea -ka -s
These options mean that all kanji (Chinese characters) and kana (Japanese syllabic characters) should be translated into romaji (alphabetical description), and words should be separated by spaces. In this experiment, I measured the response times and execution times by the http-cat command. This command is a simple HTTP client that takes a URL, gets a corresponding HTTP object from a server, and writes the contents of the object to the standard output. The response times were measured by reading the rst 1024-byte block. The execution times were measured by reading entire resource. In this experiment, I use a kanji text of which size is about 11 k bytes (350 lines of the manual of the kakasi command). This kanji text is translated into the romaji text of which size is about 12.5 k bytes. As shown in the rst columns in Figure 6(a), This translation takes 0.9 seconds by the original kakasi command if it is invoked from the command line of a UNIX shell The response time was 0.4 seconds. I measured performance in a LAN environment and a WAN environment (Figure 6(b)): LAN The regular HTTP server (Apache 1.1) runs on a Sun ULTRA1 (140MHz, main memory 64M Bytes). The stackable kakasi HTTP servers run on a Sun SS10 (40MHz SuperSPARC, main memory 48M Bytes). A simple client (http-cat) runs on another Sun. These three are connected with Ethernet (10M bit/second, no switch). WAN The regular HTTP server (Apache 1.1) runs on a Sun SS10 (40MHz SuperSPARC, main memory 96M bytes). The stackable kakasi HTTP servers run on a Sun SS10 (40MHz SuperSPARC, main memory 48M Bytes). A simple client (http-cat) runs on another Sun. These three machines are connected with a WAN (by the ping command, RTT 100 ms for a 64-byte packet, RTT 150 ms for a 1k-byte packet).
1.4
Response time
1.2
Execution time
http-cat (client)
http-cat (client)
1.0 Workstation
0.8
KAKASI server
0.6
b1
0.4
LAN: Ethernet (10Mbps, no switching Hub) WAN: RTT 100ms(64B),150ms(1KB)
Workstation
1.6
0.2 0.0
(a) Response times and excution times
Fig. 6.
Procedure (WAN)
Apache httpd (WAN)
RPC server (LAN)
External command (LAN)
Procedure (LAN)
Apache httpd (LAN)
KAKASI command (Shell)
Workstation
Apache httpd
a1 kakasi.man
(b) Configuration of objects and network
Performance of stackable kakasi HTTP servers (in seconds).
Without stackable kakasi objects, the response and execution time are about 0.03 and 0.04 seconds in the LAN environment, and 0.3 and 1.2 seconds in the WAN environment. For interactive use, response times are important. In Figure 6(a), the response times of all the stackable HTTP server are shorter than 1 second. It is enough for interactive use. Note that the response times are shorter than the execution time of the kakasi command which are invoked from the command line. This means that pipeline parallelism is exploited well in those cases. In the LAN environment, the response time of the server with the external command is longer than those in the other cases. This is because the overhead of process creation of UNIX is large. By the same reason, both the response times and the execution times of ltering by the procedure the RPC server are shorter than those of the KAKASI command. In these cases, the function of KAKASI remains in memory as a server process.
6 Related Work 6.1 DeleGate DeleGate is a general purpose gateway server [7]. In terms of object-stacking, DeleGate is a stackable server for HTTP, NNTP, Gopher, WAIS, POP, FTP, etc. DeleGate supports some built-in lters and external lters. DeleGate supports pointer swizzling (dynamic mounting) as well as static mounting. As compared with DeleGate, the rst feature of my stackable HTTP objects is that it is easier for my stackable HTTP objects to change the behavior of individual objects. In DeleGate, a small number of ags are used to change the behavior of individual objects (kanji code translation and caching). In my stackable HTTP objects, any options can be speci ed to individual objects.
The second feature of my stackable HTTP objects is that a developer of a stackable lter HTTP server can make use of skeletons and the support library at the three levels. Our stackable HTTP objects can be implemented by using not only external lter programs but also internal procedures and RPC servers.
6.2 CGI (Common Gateway Interface) Regular WWW servers provide a function, called CGI (Common Gateway Interface) which allows information providers to extend the functions of the servers. CGI is designed to call external database programs and to receive strings and mouse clicks from clients. My stackable HTTP object that invokes an external program is similar to CGI. As compared with CGI, the main feature of my stackable HTTP object is that it must take a lower object. My stackable HTTP object reads the contents of another HTTP object. A regular CGI program does not read another HTTP object. This means that a such CGI program is not stackable. An HTTP object created by a such CGI program can be used as a bottom object in my system.
6.3 Libwww Libwww includes common codes for building new WWW clients and servers [3]. This library also supports other protocols, such as Gopher, WAIS, FTP, and NNTP. As compared with libwww, one of the main features of my library described in Section 4 is that my library supports skeletons for developing virtual stackable objects and pointer swizzling. Furthermore, my library is much simpler than libwww. This is because a stackable HTTP server is much simpler than a regular WWW client and a regular WWW server. Libwww provides an abstraction named a stream. In libwww, streams are the method for transporting data from the network to application routines, or vice versa. Streams can be cascaded, and used for format conversion in the library. Streams are designed to be used within an address space. In contrast, my stackable HTTP objects stay on di erent address spaces. Streams in libwww can be used to implement a single stackable HTTP server.
7 Conclusion In this paper, I have described object-stacking on the World Wide Web. Objectstacking is a model for structuring object-based systems. One of the main features is that layers of objects with a uniform interface are constructed, and the functions of these objects are integrated. Object-stacking introduces a mechanism to integrate functions of several objects on the World Wide Web, as similar to pipes and shells in UNIX. I have implemented several stackable lter HTTP objects: conversion of image, kanjito-romaji translation, macro processing, conversion of media, and any ltering
functions provided by lter commands in UNIX. These lters can be integrated by stacking corresponding stackable objects scattered all over the world. In this integration, the interpreter of URLs acts as a shell which designates the con guration and the order of lters. This interpreter is also distributed all over the world. In object-stacking on WWW, virtual stackable objects are created recursively by the e ect of pointer swizzling. In some situation, this recursive stacking is not needed. In this paper, I have proposed a method to avoid the problem by using redirection HTTP objects. As similar to regular (bottom) objects on WWW, stackable objects should also be replicated. (Caching is a kind of replication.) If bottom HTTP objects are replicated, the upper stackable HTTP objects should also be replicated. To express these bindings between bottom objects and upper stackable objects is a challenging work.
References 1. T.Berners-Lee, Robert Cailliau, A.Luotonen, H.Frystky Nielsen, and A.Secret: \The World-Wide Web", Communications of the ACM, Vol.37, No.8, pp.76-82 (1994). 2. R.G.G.Cattell: \Object Data Management", Addison-Wesley (1991). 3. H.Frystyk, H.W.Lie: \Towards a Uniform Library of Common Code", The Second International WWW Conference '94, (1994). 4. \Image Machine", http://www.vrl.com/Imaging/, 1997. 5. \ImageMagick", http://www.wizards.dupont.com/cristy/ImageMagick.html, 1997. 6. A.Luotonen, and K.Altis: \World-Wide Web Proxies", First International Conference on the World-Wide Web (WWW'94), May 1994. 7. Y.Sato: \Multipurpose Protocol Mediation System: DeleGate", The bulletin of ETL (Electrotechnical Laboratory), Vol.59, No.6 (1995).
8. Y.Shinjo, S.Zakimi and S.Kyan: \Object-Stacking in the World Wide Web", Proc. 4th International Workshop on Object Orientation in Operating Systems (I-WOOOS'95), pp.210-219 (1995).
9. Y.Shinjo and Y.Kiyoki: \The Object-Stacking Model for Structuring Object-Based Systems", Proc. 2nd International Workshop on Object Orientation in Operating Systems (I-WOOOS'92), pp.328-340 (1992). 10. H.Takahashi: \KAKASI { Kanji Kana Simple Inverter", (1994).
11. P.R.Willson and S.V.Kakkad: \Pointer Swizzling at Page Fault Time: Eciency and Compatibly Supporting Huge Address Spaces on Standard Hardware", Proc. 2nd International Workshop on Object Orientation in Operating Systems (IWOOOS'92), pp.364-377 (1992). This article was processed using the LaTEX macro package with LLNCS style
