Clasificación de usos del Suelo Suburbano

The first implementation attempt of the WebAudio client investigated to realize the appli-

cation as a Web browser plug-in15. Since the WebAudio client application is intended to

be used within the WWW, the extension of the Web browser seemed to be an elegant way to integrate WebAudio.

15_{A plug-in is in general an application extension in form of a Dynamic Link Library (DLL) or shared}

4.2. IMPLEMENTATION ISSUES 129 Implementing the client application as a Netscape browser plug-in, however, soon showed the limits of such plug-ins. Since Netscape plug-ins are executed within the Web browser’s main process – no separate thread or process is executed – it is impossible to control the network communication and the sound device within WebAudio in an appropriate manner. Plug-ins simply have no sufficient control on the program flow because they are merely built of a few functions that are called upon certain Web browser events. As a result, synchronous commands such as the “select” system call cannot be used since they would block the whole Web browser process. Moreover, the main intention of Web browser plug-ins is to process data which is delivered in-band by HTTP. A typical example of a Web browser plug-in is a PDF viewer. Upon a HTTP request of a PDF document, the browser passes the Entity Body of the HTTP response to the plug-in which then displays the PDF document in response. In the case of WebAudio, however, the problem is completely different. The audio stream data is not transmitted in-band by HTTP. As a result the WebAudio client must be able to actively listen on a socket port. Since the plug-in has no real control on the program flow, it cannot listen on the port. One solution for this problem could be the use of a plug-in threads which actively listen on the receiving port. However, this approach failed since the FreeBSD release of Netscape’s Web browser (Communicator

4.07) is not linked with thread save libraries16 Moreover, the thread based solution is not

suitable for several reasons discussed in section 4.2.1.

In addition, Web browser plug-ins have the disadvantage that they rely on the proper operation of the browser. If the browser malfunctions (for example, hangs for a moment due to an unresolved DNS lookup or an unconfirmed message box), the plug-in is also hindered from proper operation.

Another important argument against implementing the WebAudio client as a Web browser plug-in is the compatibility and support of such plug-ins. Not only are plug-ins usu-

ally developed especially for one Web browser, such as Microsoft’s Internet Explorer17 or

Netscape’s Communicator, they also behave differently on miscellaneous platforms (if avail-

able at all18), due to the different Web browser implementations. Although, for example,

the plug-in interface of Netscape’s Web browsers is the same on all platforms, noticeable differences in the behavior of the Communicator 4.07 for Windows 95 and FreeBSD are observable.

Helper applications, in contrast, are an alternative method to extend the functionality of Web browsers. Helper applications are stand-alone applications that are executed by the Web browser upon receipt of a certain MIME type. The Entity Body of the HTTP response is passed to the application through the standard input interface.

Helper applications have several advantages over plug-ins. First, they are supported by almost any Web browser – mainly due to the simple interface. Second, they are executed

16_{Such libraries are able to handle multiple threads without interfering with re-entrant system calls.} 17_{In the context of Microsoft’s Internet Explorer plug-ins are usually called ActiveX controls.}

18_{Microsoft’s Internet Explorer is not available for many other operating systems apart from the Mi-}

in a separate process. Thus, the application has full control over the program flow which greatly simplifies the problem of concurrent processing of time-critical operations, such as listening on a receiver port while decoding and playing back the audio data in time. Third, since helper applications are executed independently from the Web browser process, problems caused by differences in cross platform browser implementations do not arise. The main drawback of using helper applications is that the Web integration is not as thorough. While plug-ins are up-called on relevant Web browser events (for example, window closed, page unload, etc.), helper applications are not informed. This disadvantage, however, is less significant in the context of WebAudio since the client application offers a HTTP based control interface. Java Script, for example, can be used to forward Web browser events to the client application by means of HTTP-URL requests.

In retrospect, the discussion of this section has shown that the implementation of the WebAudio client as a helper applications has significant benefits over the implementation as a Web browser plug-in.