Removing obsolete files
svn: r6438
This commit is contained in:
Jay McCarthy
parent
1090572e21
commit
15b97fa4f8
|
|
@ -1,347 +0,0 @@
|
||||||
_prototype-web-server_
|
|
||||||
|
|
||||||
_Overview_
|
|
||||||
|
|
||||||
The prototype is intended to completely decouple the continuation mechanism
|
|
||||||
for servlets from the rest of the server. The prototype-server knows
|
|
||||||
nothing about continuations. Instead, the prototype-server provides a
|
|
||||||
simple session-based model akin to traditional CGI.
|
|
||||||
|
|
||||||
See prototype-web-server/servlets/add01.ss for an example session-based
|
|
||||||
servlet.
|
|
||||||
|
|
||||||
See Web Interactive Language, and Interactive Language for understanding
|
|
||||||
how continuations are used with the prototype-web-server.
|
|
||||||
|
|
||||||
_Configuring the prototype-server_
|
|
||||||
|
|
||||||
Eliminated the dependency on web-server/configuration.ss and simply
|
|
||||||
hard-coded the configuration in:
|
|
||||||
prototype-web-server/hardcoded-configuration.ss
|
|
||||||
|
|
||||||
|
|
||||||
_Running the prototype-server_
|
|
||||||
> serve
|
|
||||||
;; serve: -> -> void
|
|
||||||
;; start the server and return a thunk to shut it down.
|
|
||||||
|
|
||||||
_Loading Servlets_
|
|
||||||
|
|
||||||
Steps:
|
|
||||||
1. The URL is decoded. If the URL encodes a session-id, then the server
|
|
||||||
looks up the session in the session table. If the session structure is
|
|
||||||
found in the table, then the session-handler is called with the request
|
|
||||||
to generate the response. If no session is found an error page is
|
|
||||||
generated.
|
|
||||||
|
|
||||||
2. If the URL does not encode a session-id, then the servlet path is
|
|
||||||
resolved to find an executable (see path resolution.) If no executable
|
|
||||||
is found, an error page is generated.
|
|
||||||
|
|
||||||
3. If an executable is found a new session-structure is created. A unique
|
|
||||||
session-id is generated for the session and all subsequent requests for
|
|
||||||
this session should encode this id. A new custodian, new namespace, and
|
|
||||||
a default handler are created for the session. The simplified url-path
|
|
||||||
that located the servlet is used as the path in the session-url.
|
|
||||||
|
|
||||||
4. The servlet executable should be a module. The servlet is then invoked
|
|
||||||
via dynamic-require within the new session-namespace. During this
|
|
||||||
invocation, the servlet should make a call to start-session in order to
|
|
||||||
install the session handler for the servlet. After the module is
|
|
||||||
invoked, the session handler is called with the initial request.
|
|
||||||
|
|
||||||
_Path Resolution_
|
|
||||||
|
|
||||||
Steps:
|
|
||||||
1. The url-path is simplified:
|
|
||||||
(i) All path/params are removed from the url path and replaced with
|
|
||||||
their corresponding path/param-path.
|
|
||||||
(ii) Empty strings that show up as file names in the url-path are removed
|
|
||||||
from the path, so that e.g. a path that looks like "foo////bar"
|
|
||||||
would be simplified to "foo/bar".
|
|
||||||
(iii) All ".."'s are removed from the path by replacing them with 'up.
|
|
||||||
(iv) The path is simplified with respect to the root directory in order
|
|
||||||
to prevent path chasing. I.e. if surplus ".." pile up they are
|
|
||||||
discarded.
|
|
||||||
2. The path is appended to the servlet-path of the virtual-host that is
|
|
||||||
handling the request.
|
|
||||||
3. The shortest prefix of the path from step 2 that specifies a servlet
|
|
||||||
file is then computed. The resulting servlet file is the one.
|
|
||||||
4. The same prefix in step 3, but without the servlet-path part, is used
|
|
||||||
for the url-path in the session-url. The session-id will be encoded in
|
|
||||||
this path.
|
|
||||||
|
|
||||||
_Sessions_
|
|
||||||
_session.ss_
|
|
||||||
|
|
||||||
The prototype web-server creates a session each time a particular servlet
|
|
||||||
is loaded. A servlet is loaded when the URL specifying the servlets
|
|
||||||
filename does not encode a session id. A new namespace is created and
|
|
||||||
stored as part of the session. The servlet is then dynamic-required using
|
|
||||||
the new namespace. The module session.ss is attached to the servlets
|
|
||||||
namespace.
|
|
||||||
|
|
||||||
NOTE: The session is analogous to the "servlet-instance" in the current
|
|
||||||
web-server.
|
|
||||||
|
|
||||||
The servlet-writer should be aware of the following provides from
|
|
||||||
session.ss:
|
|
||||||
|
|
||||||
[struct session ([id number?]
|
|
||||||
[cust custodian?]
|
|
||||||
[namespace namespace?]
|
|
||||||
[handler (request? . -> . response?)]
|
|
||||||
[url url?])]
|
|
||||||
|
|
||||||
> session-id
|
|
||||||
A number that identifies the session. This number is encoded in the URL and
|
|
||||||
used by the server to lookup the correct session for an incoming
|
|
||||||
request. session-id's are encoded using a path/param.
|
|
||||||
|
|
||||||
> session-custodian
|
|
||||||
The custodian that manages the session.
|
|
||||||
|
|
||||||
NOTE: Sessions currently do NOT time out. Ultimately I will need to add a
|
|
||||||
timeout mechanism for sessions so that they don't pile up and consume
|
|
||||||
memory. This is the same as the servlet-timeout.
|
|
||||||
|
|
||||||
> session-namespace
|
|
||||||
The namespace in which the servlet runs.
|
|
||||||
|
|
||||||
NOTE: Each session gets its own namespace. It is presently NOT easy for two
|
|
||||||
sessions to share state.
|
|
||||||
|
|
||||||
REQUIREMENT: Need a mechanism for sessions to share state through a common
|
|
||||||
module. This includes sessions corresponding to different servlets.
|
|
||||||
|
|
||||||
> session-handler
|
|
||||||
The session handler consumes a request and produces a response. All
|
|
||||||
requests for the session go through the session handler. The
|
|
||||||
session-handler is installed via a call to start-session.
|
|
||||||
|
|
||||||
> session-url
|
|
||||||
The minimal url that refers to the servlet file. It is minimal in the sense
|
|
||||||
that the url-path is the shortest path that would resolve to the
|
|
||||||
servlet. This url-path also encodes the session id.
|
|
||||||
|
|
||||||
> current-session
|
|
||||||
This parameter is set by the web-server and stores the value of the current
|
|
||||||
session.
|
|
||||||
|
|
||||||
> lookup-session
|
|
||||||
(number? . -> . (union session? boolean?))
|
|
||||||
lookup-session is used internally by the web-server to lookup a session
|
|
||||||
once the session-id is decoded from the URL.
|
|
||||||
|
|
||||||
> new-session
|
|
||||||
(custodian? namespace? url? . -> . session?)
|
|
||||||
new-session is used internally by the web-server to create a new session
|
|
||||||
when a servlet is loaded.
|
|
||||||
|
|
||||||
> start-session
|
|
||||||
((request? . -> . response?) . -> . any)
|
|
||||||
start-session installs the session-handler for a servlets session. Start
|
|
||||||
session should be called by the servlet exactly once before any responses
|
|
||||||
are generated.
|
|
||||||
|
|
||||||
_utils.ss_
|
|
||||||
|
|
||||||
> split-url-path
|
|
||||||
;; url url -> (union (listof string) #f)
|
|
||||||
Useful when using the servlet-path to encode additional arguments to the
|
|
||||||
server. Servlet writers should use this to recover the suffix of the
|
|
||||||
url-path occurring after the servlet file.
|
|
||||||
|
|
||||||
> url->servlet-path
|
|
||||||
url->servlet-path: path url -> (values (union path #f)
|
|
||||||
(union (listof url->string) #f)
|
|
||||||
(union (listof string) #f))
|
|
||||||
Used by the server during servlet-path resolution.
|
|
||||||
|
|
||||||
> make-session-url
|
|
||||||
url (listof string) -> url
|
|
||||||
Used internally by the server to create the session-url when loading a
|
|
||||||
servlet.
|
|
||||||
|
|
||||||
_Interaction Language_
|
|
||||||
|
|
||||||
The interaction language creates a module with multiple interaction
|
|
||||||
points. The interaction point serves as a synchronization mechanism between
|
|
||||||
the module and the outside world. When an interaction point is encountered,
|
|
||||||
a response is generated by the module and then execution halts. Execution
|
|
||||||
may be resumed later when a request is passed to the module. The
|
|
||||||
interactive language, by itself does not restrict the number of times an
|
|
||||||
interaction point can be resumed.
|
|
||||||
|
|
||||||
The syntax of an interactive module is as follows:
|
|
||||||
|
|
||||||
program ::= definition* expr
|
|
||||||
|
|
||||||
definition ::= (define-values (var) expr)
|
|
||||||
|
|
||||||
expr ::= var
|
|
||||||
| (lambda (var ...) expr)
|
|
||||||
| (if expr expr)
|
|
||||||
| (if expr expr expr)
|
|
||||||
| (let-values ([(var)] expr) expr)
|
|
||||||
| (#%app expr ...)
|
|
||||||
| (#%datum . datum)
|
|
||||||
| (#%top . var)
|
|
||||||
| (begin expr ...)
|
|
||||||
|
|
||||||
NOTE: The body of the module (excluding requires) is first expanded to
|
|
||||||
core-mzscheme forms before execution.
|
|
||||||
|
|
||||||
NOTE: The interaction language is implemented using non-native
|
|
||||||
continuations. I.e. occurrences of call/cc within the program are replaced
|
|
||||||
by a new version when the module is expanded.
|
|
||||||
|
|
||||||
_Creating an Interactive Module_
|
|
||||||
|
|
||||||
An interactive module is created by specifying "interaction.ss" as the language
|
|
||||||
for a module.
|
|
||||||
|
|
||||||
Example:
|
|
||||||
(module my-module "interaction.ss"
|
|
||||||
...)
|
|
||||||
|
|
||||||
The writer of an interactive module may then specify interaction points
|
|
||||||
using the interface provided by interaction.ss
|
|
||||||
|
|
||||||
_interaction.ss_
|
|
||||||
|
|
||||||
> start-interaction
|
|
||||||
(request -> continuation) -> request
|
|
||||||
start-interaction establishes the initial interaction point for the
|
|
||||||
interactive module and registers a procedure to be used for decoding
|
|
||||||
requests. start-interaction stores the continuation of the call to
|
|
||||||
start-interaction. This continuation is resumed using the client interface
|
|
||||||
to the interactive module (see below.)
|
|
||||||
|
|
||||||
Example:
|
|
||||||
(module m01 "../interaction.ss"
|
|
||||||
(define (id x) x)
|
|
||||||
(+ (* 1 2) (* 3 4) (start-interaction id)))
|
|
||||||
|
|
||||||
> send/suspend
|
|
||||||
(continuation -> response) -> request
|
|
||||||
Captures the continuation of the call to send/suspend and passes this as
|
|
||||||
the argument to send/suspend. Execution then halts until the continuation
|
|
||||||
is resumed via the client interface to the interactive module (see below.)
|
|
||||||
|
|
||||||
_client.ss_
|
|
||||||
|
|
||||||
> dispatch-start
|
|
||||||
request -> response
|
|
||||||
Pass the initial request to the interactive module. After the module is
|
|
||||||
required, it should eventually make a call to start-interaction. After
|
|
||||||
start-interaction is called, execution will halt until dispatch-start is
|
|
||||||
called. When dispatch-start is called, the request is passed to the
|
|
||||||
continuation of the call to start-interaction. The response produced is the
|
|
||||||
response produced by the next interaction point of the module or, when no
|
|
||||||
subsequent interaction point is encountered, is the result of evaluating
|
|
||||||
the module's body expression.
|
|
||||||
|
|
||||||
> dispatch
|
|
||||||
request -> response
|
|
||||||
Resumes execution at the interaction point encoded in the request. When
|
|
||||||
dispatch is called, the request handler installed via the last call to
|
|
||||||
start-interaction is applied to the request, producing a continuation and
|
|
||||||
then the resulting continuation is applied to the request. The response
|
|
||||||
produced is the response produced by the next interaction point of the
|
|
||||||
module or, when no subsequent interaction point is encountered, is the
|
|
||||||
result of evaluating the module's body expression.
|
|
||||||
|
|
||||||
When only "one-shot" continuations are needed, make multiple calls to
|
|
||||||
start-interaction.
|
|
||||||
|
|
||||||
Example:
|
|
||||||
(module m02 "../interaction.ss"
|
|
||||||
(define (id x) x)
|
|
||||||
(+ (start-interaction id)
|
|
||||||
(start-interaction id)))
|
|
||||||
|
|
||||||
(require m02)
|
|
||||||
(void? (dispatch-start 1))
|
|
||||||
(= 3 (dispatch-start 2))
|
|
||||||
(= 0 (dispatch-start -1))
|
|
||||||
|
|
||||||
In the next example, send/suspend is used to establish re-usable
|
|
||||||
interaction points. An auxiliary module, table, is used to store
|
|
||||||
continuations so that they may be used multiple times. Keys are associated
|
|
||||||
with continuations in a hash table. The module body evaluates to a number,
|
|
||||||
while interaction points within the computation yield the continuation key
|
|
||||||
corresponding to that particular continuation. So a response is either a
|
|
||||||
number or a key. A request consists of a key paired with a number. The
|
|
||||||
initial request is ignored.
|
|
||||||
|
|
||||||
Example:
|
|
||||||
(module table mzscheme
|
|
||||||
(provide store-k
|
|
||||||
lookup-k)
|
|
||||||
|
|
||||||
(define the-table (make-hash-table))
|
|
||||||
|
|
||||||
;; store-k: continuation -> symbol
|
|
||||||
(define (store-k k)
|
|
||||||
(let ([key (string->symbol (symbol->string (gensym 'key)))])
|
|
||||||
(hash-table-put! the-table key k)
|
|
||||||
key))
|
|
||||||
|
|
||||||
;; lookup-key: (list symbol number) -> continuation
|
|
||||||
(define (lookup-k key-pair)
|
|
||||||
(hash-table-get the-table (car key-pair) (lambda () #f))))
|
|
||||||
|
|
||||||
(module m06 "../interaction.ss"
|
|
||||||
(require table)
|
|
||||||
|
|
||||||
;; gn: string -> number
|
|
||||||
;; Get a number from the client.
|
|
||||||
(define (gn which)
|
|
||||||
(cadr
|
|
||||||
(send/suspend
|
|
||||||
(lambda (k)
|
|
||||||
(let ([ignore (printf "Please send the ~a number.~n" which)])
|
|
||||||
(store-k k))))))
|
|
||||||
|
|
||||||
;; get two numbers from the client and produce their sum
|
|
||||||
(let ([ignore (start-interaction lookup-k)])
|
|
||||||
(let ([result (+ (gn "first") (gn "second"))])
|
|
||||||
(let ([ignore (printf "The answer is: ~s~n" result)])
|
|
||||||
result))))
|
|
||||||
|
|
||||||
(require m06)
|
|
||||||
|
|
||||||
;; client code.
|
|
||||||
(let* ([first-key (dispatch-start 'foo)]
|
|
||||||
[second-key (dispatch `(,first-key 1))]
|
|
||||||
[third-key (dispatch `(,first-key -7))])
|
|
||||||
(values
|
|
||||||
(= 3 (dispatch `(,second-key 2)))
|
|
||||||
(= 4 (dispatch `(,second-key 3)))
|
|
||||||
(zero? (dispatch `(,second-key -1)))
|
|
||||||
(= -7 (dispatch `(,third-key 0)))
|
|
||||||
(zero? (dispatch `(,third-key 7)))))
|
|
||||||
|
|
||||||
_Web Interaction Language_
|
|
||||||
|
|
||||||
_web-interaction.ss_
|
|
||||||
|
|
||||||
Use this language for writing servlets.
|
|
||||||
|
|
||||||
> start-servlet
|
|
||||||
-> request
|
|
||||||
Set the initial interaction point for the servlet. This analogous to
|
|
||||||
start-interaction the request handler is built-in and decodes the
|
|
||||||
continuation-id from the URL. The return value of start-servlet is the
|
|
||||||
initial HTTP request.
|
|
||||||
|
|
||||||
> send/suspend
|
|
||||||
(url -> response) -> request
|
|
||||||
Send a response to the client and wait for the request. The continuation of
|
|
||||||
the call to send/suspend is encoded in the URL that is passed to the
|
|
||||||
argument of send/suspend. The argument should produce a request (usually an
|
|
||||||
xexpr).
|
|
||||||
|
|
||||||
See collects/prototype-web-server/servlets/
|
|
||||||
for examples of servlets written using the "web-interaction.ss" language.
|
|
||||||
|
|
@ -1,4 +0,0 @@
|
||||||
(module info (lib "infotab.ss" "setup")
|
|
||||||
(define name "Prototype Web Server")
|
|
||||||
(define doc.txt "doc.txt"))
|
|
||||||
|
|
||||||
Loading…
Reference in New Issue
Block a user