Lecture 4

1. Recap of the System class
- it is a utility class by virtue of the absence of a constructor. It is not the presence of static methods that makes a class a utility class - remember, even non-utility classes can have static methods. In fact, a class could be defined such that it has a constructor and all of its methods are static - such a class still would not be a utility class.
-System has three publically-accessible fields - in, out, and err. The latter two are of type PrintStream. System HAS-A attribute that is a PrintStream object (it just so happens that out and err, by default, refer to the same PrintStream object, namely the one that encapsulates the console).
==> UML diagrams to represent this relationship between classes (see Ch2 for review of UML, see sec 7.1.3 for the three different inter-class relationships and the notation)

2. Overview of Input Streams (reference: case study 8.1.5)
-establishes a data conduit from a source (some place from which a data stream might be issued forth) to a receiver or "data sink" (our program)
-we read from the stream byte by byte; the stream will block until there is something to send
-the work of turning the byte stream into a character stream, this is the role of the buffer. The buffer needs to know something about the the platform's charset. This is delegated to a separate module (the reader)
-the work of delivering the character stream to us, a line at a time, is the buffer
-the charset tells us - how to interpret a particular byte? is it ascii?is it UTF-8
Eight-bit UCS Transformation Format? we then map between different character encoding schemes to Unicode
==> Key point - in constructing a Scanner object, we pass to the Scanner constructor an object that represents an InputStream. Typically, we use System.in, but the next part of lecture shows that we can use an InputStream that encapsulates the data flow from a web server.

3. Basic WWW concepts:
- http protocol is mechanism for communication between "browsers" and servers
- stateless (meaning no information saved from one exchange to the next) - can demonstrate by contrast to human conversation (which is state-based)
-there are two players - the "browser" who makes GET/POST requests, and the server who responds to them
-use FireBug to illustrate the browser issuing the GET/POST requests and the responses from the server.
-a component of the GET request is the URL
-the URL consists of http:// prefix, server specification, resource path, arguments, (and part)
e.g., in the URL
http://www.cse.yorku.ca/~roumani/jba/ase/se.cgi?hrss=+.AB, the part "hrss=+.AB" is the argument list
-how do URL's get composed?
-within browser - can have
element within html, has functionality to compose the argument list on the basis of user input
for instance, look at page source at http://www.cse.yorku.ca/~roumani/jba/ase/index.html
-also can do so programmatically composing name/value pairs by string concatenation (foreshadow - do we have a way to programmatically issue GET/POST request to a server)
-server-side processing unpacks the argument list and then invokes some code that generates a response.
-notice that one can manually compose the URL with name/value pairs.
-we can use services of URL class (in java.net package) to open an InputStream that corresponds to what the server will serve up (deliver in response to a request)
-
in-class development of solution to Lab7.3