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, objects are classified into two types: bottom objects and stackable objects. Each bottom object provides a primitive function. Each stackable object provides a high-level function, such as filtering, 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 [1]. 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.
Unlike stackable file objects, stackable HTTP objects are created on demand. Stacks of objects are created by accessing with the object ids (URLs) first, and then stacks of objects are created later.
A stackable HTTP object is an stackable object which is managed by an HTTP server, and provides a high-level function such as filtering, masking, or caching. Filtering includes conversion of image, translation of character encoding methods, macro processing, conversion of media, and any filtering functions provided by the filter commands in UNIX.
Figure 1 shows two stacks of HTTP objects. The concrete objects in Figure 1 provide the following functions, respectively:
- (c1, c2) These objects scale down 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 accesses
through a narrow communication line.
- (b1, b2) These objects translate kanji into romaji for text objects, and do
nothing for other types of objects. Romaji is an alphabetical
description of Japanese pronunciation. It is very useful for people in the
other countries to view WWW pages in Japanese kanji (Chinese characters)
without special equipments for Japanese.
- (a1, a2) These objects store data.
These functions are integrated into the top objects, Object c1 and c2. That is, a romaji text object and a small image object are created.
Figure 2 shows the effects of the stackable objects. On the left of Figure 2, a large image and kanji characters are displayed. These correspond to Object a1 and a2 in Figure 1. On the right of Figure 2, a small image and romaji (alphabet characters) are displayed. These correspond to Object c1 and c2 in Figure 1. The kanji-to-romaji translation is done by KAKASI [2].
Each stackable HTTP object is identified 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 1, for example, Object c1, b1, and a1 are identified by the following URLs, respectively:
(c1) http://hostC:portC/-scale+0.5x0.5!
http://hostB:portB/-Ha+-Ka+-Ja+-s!
http://hostA:portA/Welcome-j.html
(b1) http://hostB:portB/-Ha+-Ka+-Ja+-s!
http://hostA:portA/Welcome-j.html
(a1) http://hostA:portA/Welcome-j.html
HTML objects in WWW include references (URLs) to other objects. To implement object-stacking, these references should be rewritten consistently. We call this rewriting pointer swizzling [1]. For example, in Figure 1, there are two bottom objects, Object a1 and Object a2. On those two objects, Object b1 and Object b2 are stacked, respectively. Object a1 in Figure 1 include the reference to Object a2. In other words, Object a1 includes the URL of Object a2. In Object b1, this reference (URL) should be rewritten to the URL of Object b2.
Each developer of a server of stackable filter HTTP objects can make use the system support facility at the following three levels: (1) The procedure level, (2) The command level, and (3) The RPC level. Each developer of a stackable HTTP server chooses one of the three levels, and writes her/his filter which interface fits the chosen level.
DeleGate is an HTTP server which provides filtering functions [3]. Besides HTTP, DeleGate supports other protocols, such as NNTP, Gopher, WAIS, POP, FTP, etc. As compared with DeleGate, the first feature of my stackable HTTP objects is that it is easier to describe behavior of individual objects. The second feature of my stackable HTTP objects is that a developer of a stackable filter HTTP server can make use of skeletons and the support library at the three levels.
1. Y.Shinjo, S.Zakimi, S.Kyan, Object-Stacking in the World-Wide Web, Proc. IEEE 4th International Workshop on Object Orientation in Operating Systems, Aug.1995, pp.210-219.
<http://bottom.ie.u-ryukyu.ac.jp/~yas/shinjo-papers/shinjo-iwooos-95.ps.Z>
2. H.Takahashi, KAKASI - kanji kana simple inverter, (1994).
<ftp://sunsite.sut.ac.jp/pub/asia-info/japanese-src/packages/kakasi-2.2.5.tar.gz>
3. Y.Sato, Multipurpose Protocol Mediation System: DeleGate, The bulletin of ETL (Electrotechnical Laboratory), Vol.59, No.6 (1995).
<http://www.etl.go.jp:8080/etl/People/ysato@etl.go.jp/DeleGate/>
