You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@commons.apache.org by gs...@apache.org on 2003/10/30 12:01:18 UTC

svn commit: rev 60 - in commons/serf/branches/gen2: . test

Author: gstein
Date: Thu Oct 30 03:01:17 2003
New Revision: 60

Modified:
   commons/serf/branches/gen2/STATUS
   commons/serf/branches/gen2/context.c
   commons/serf/branches/gen2/serf.h
   commons/serf/branches/gen2/test/serf_get.c
Log:
Update the acceptor callback handling, and add some skeleton code for the
request processing.

* serf/branches/gen2/STATUS: update some notes

* serf/branches/gen2/serf.h:
  (serf_context_run): note that APR_TIMEUP is returned when the
    connections have been inactive for the specified duration.
  (serf_connection_create): move the acceptor to the request creation
    function. We want to enable per-request acceptors since those define
    which buckets are wrapped around the socket, and (thus) how the
    response data is manipulated and processed.
  (serf_connection_request_create): add the acceptor callbacks. remove the
    bucket allocator since the core system doesn't actually create
    buckets; we get a request bucket passed to us, and the acceptor
    callback creates the response buckets.

* serf/branches/test/serf_get.c:
  (main): adjust parameters to compensate for the changes to
    serf_connection_create and serf_connection_request_create.

* serf/branches/test/context.c:
  (struct serf_connection_t): add structure which got dropped during the
    merge of context.c and connection.c
  (request_t): new structure to hold some per-request tracking info.
  (process_creation): was serf_connection_process; the name doesn't have
    to follow the strict namespacing since it is now internal.
  (add_connection, remove_connection): renamed from
    serf_context_add_connection and serf_context_remove_connection,
    respectively. we don't need the hard-core namespacing for internal
    functions.
  (serf_connection_create): remove the acceptor callback and its baton.
  (serf_connection_request_create): add the acceptor callback and its
    baton, and remove the bucket allocator.


Modified: commons/serf/branches/gen2/STATUS
==============================================================================
--- commons/serf/branches/gen2/STATUS	(original)
+++ commons/serf/branches/gen2/STATUS	Thu Oct 30 03:01:17 2003
@@ -19,6 +19,10 @@
                  have a better idea how the buckets are going to operate.  I'd
                  like to get a better idea how filters are going to be written
                  before deciding upon our pool usage.
+    gstein says: I think an allocator will be used for for a whole
+                 context's worth of buckets. any pool within this
+                 system ought to be transaction-scoped (e.g. tied to a
+                 particular request/response pair).
 
   * the current definition has a "metadata" concept on a per-bucket
     basis. however, to record this metadata, we really want to be able
@@ -36,13 +40,36 @@
     Justin says: We want bucket to be an aggregate bucket, and for the first
                  bucket in that aggregate bucket to be the 'original' bucket.
                  I think we just swap internal data structures, but not sure.
+    gstein says: we don't necessarily want to preserve the original
+                 bucket. consider a REQUEST bucket which could
+                 "become" an aggregate containing two buckets: one for
+                 the serialized request-line and headers, and one for
+                 the body. there is no REQUEST bucket any more.
 
   * If anyone knows how to use APR_RING, we could probably use that for the
     aggregate bucket list.
+    gstein says: I think this implies a little entry structure which
+                 contains the "link", plus a pointer to the bucket. I
+                 was thinking of just using an apr array.
 
   * How does something like deflate get inserted into both the request and
     response?
-    Justin says: I'm still not crystal clear on how this should work.  I'd like
-                 the concept of a 'filter' somehow as we can shield the 'user
-                 programmer' from this, but I dunno.  A 'hook' after the request
-                 is created, but before it is sent???
+    Justin says: I'm still not crystal clear on how this should work.
+                 I'd like the concept of a 'filter' somehow as we can
+                 shield the 'user programmer' from this, but I dunno.
+                 A 'hook' after the request is created, but before it
+                 is sent???
+    gstein says: when assembling the request bucket, a "deflate"
+                 bucket can be wrapped around the body bucket. it
+                 reads raw content, compresses it, and returns
+                 that. when a response arrives, an "inflate" bucket is
+                 wrapped around the body bucket to inflate the
+                 response. (of course, the decision points are made
+                 based upon headers and server capabilities whatnot)
+
+                 filters are just buckets that wrap other buckets.
+
+  * how to signify "bucket is done"? len==0? NULL data pointer? return
+    APR_EOF? Note that we intend for the response handler to return
+    APR_EOF to denote that the response has been completely read. I'm
+    of a mind to say "return APR_EOF".

Modified: commons/serf/branches/gen2/context.c
==============================================================================
--- commons/serf/branches/gen2/context.c	(original)
+++ commons/serf/branches/gen2/context.c	Thu Oct 30 03:01:17 2003
@@ -69,9 +69,38 @@
     apr_array_header_t *conns;
 };
 
+struct serf_connection_t {
+    serf_context_t *ctx;
 
-static apr_status_t serf_connection_process(serf_connection_t *conn,
-                                            apr_int16_t events)
+    apr_pool_t *pool;
+
+    apr_socket_t *skt;
+
+    serf_connection_closed_t closed;
+    void *closed_baton;
+};
+
+typedef struct {
+    apr_pool_t *respool;
+
+    serf_bucket_t *req_bkt;
+
+    void *unwritten_ptr;
+    apr_size_t *unwritten_len;
+
+    serf_response_acceptor_t acceptor;
+    void *acceptor_baton;
+
+    serf_response_handler_t handler;
+    void *handler_baton;
+
+    serf_bucket_t *resp_bkt;
+
+} request_t;
+
+
+static apr_status_t process_connection(serf_connection_t *conn,
+                                       apr_int16_t events)
 {
     return APR_SUCCESS;
 }
@@ -113,7 +142,7 @@
     while (num--) {
         serf_connection_t *conn = desc->client_data;
 
-        status = serf_connection_process(conn, desc++->rtnevents);
+        status = process_connection(conn, desc++->rtnevents);
         if (status) {
             /* ### what else to do? */
             return status;
@@ -124,8 +153,8 @@
 }
 
 
-static apr_status_t serf_context_add_connection(serf_context_t *ctx,
-                                                serf_connection_t *conn)
+static apr_status_t add_connection(serf_context_t *ctx,
+                                   serf_connection_t *conn)
 {
     apr_pollfd_t desc = { 0 };
 
@@ -137,8 +166,8 @@
     return apr_pollset_add(ctx->pollset, &desc);
 }
 
-static apr_status_t serf_context_remove_connection(serf_context_t *ctx,
-                                                   serf_connection_t *conn)
+static apr_status_t remove_connection(serf_context_t *ctx,
+                                      serf_connection_t *conn)
 {
     apr_pollfd_t desc = { 0 };
 
@@ -151,8 +180,6 @@
 SERF_DECLARE(serf_connection_t *) serf_connection_create(
     serf_context_t *ctx,
     apr_sockaddr_t *address,
-    serf_response_acceptor_t acceptor,
-    void *acceptor_baton,
     serf_connection_closed_t closed,
     void *closed_baton,
     apr_pool_t *pool)
@@ -161,11 +188,14 @@
 
     conn->ctx = ctx;
     conn->pool = pool;
-    conn->acceptor = acceptor;
-    conn->acceptor_baton = acceptor_baton;
     conn->closed = closed;
     conn->closed_baton = closed_baton;
 
+    if (add_connection(ctx, conn)) {
+        /* ### what to do with the error? */
+        return NULL;
+    }
+
     return conn;
 }
 
@@ -173,9 +203,10 @@
 SERF_DECLARE(apr_status_t) serf_connection_request_create(
     serf_connection_t *conn,
     serf_bucket_t *request,
+    serf_response_acceptor_t acceptor,
+    void *acceptor_baton,
     serf_response_handler_t handler,
     void *handler_baton,
-    serf_bucket_alloc_t *allocator,
     apr_pool_t *pool)
 {
     return APR_ENOTIMPL;

Modified: commons/serf/branches/gen2/serf.h
==============================================================================
--- commons/serf/branches/gen2/serf.h	(original)
+++ commons/serf/branches/gen2/serf.h	Thu Oct 30 03:01:17 2003
@@ -119,6 +119,9 @@
  * return with APR_SUCCESS. Typically, the caller will just want to call it
  * again to continue processing data.
  *
+ * If no activity occurs within the specified timeout duration, then
+ * APR_TIMEUP is returned.
+ *
  * All temporary allocations will be made in @a pool.
  */
 SERF_DECLARE(apr_status_t) serf_context_run(serf_context_t *ctx,
@@ -208,11 +211,6 @@
  * destroying this pool will close the connection, and terminate any
  * outstanding requests or responses.
  *
- * When a response arrives, the @a acceptor will be called with the
- * incoming socket (and the baton provided in @a acceptor_baton). A bucket
- * should be created and returned, which will be used as the response
- * bucket and passed to the associated request's response handler.
- *
  * When the connection is closed (upon request or because of an error),
  * then the @a closed callback is invoked, and @a closed_baton is passed.
  *
@@ -225,8 +223,6 @@
 SERF_DECLARE(serf_connection_t *) serf_connection_create(
     serf_context_t *ctx,
     apr_sockaddr_t *address,
-    serf_response_acceptor_t acceptor,
-    void *acceptor_baton,
     serf_connection_closed_t closed,
     void *closed_baton,
     apr_pool_t *pool);
@@ -235,9 +231,9 @@
  * Create a new request for the specified @a connection.
  *
  * The request is specified by the @a request bucket. When a response
- * arrives, @a handler will be invoked with the response bucket (allocated
- * using the @a allocator bucket allocator). The @a handler_baton will be
- * passed to the handler.
+ * arrives, the @a acceptor callback will be invoked (along with the
+ * @a acceptor_baton) to produce a response bucket. That bucket will then
+ * be passed to @a handler, along with the @a handler_baton.
  *
  * All temporary allocations will be made in @a pool.
  */
@@ -245,9 +241,10 @@
 SERF_DECLARE(apr_status_t) serf_connection_request_create(
     serf_connection_t *conn,
     serf_bucket_t *request,
+    serf_response_acceptor_t acceptor,
+    void *acceptor_baton,
     serf_response_handler_t handler,
     void *handler_baton,
-    serf_bucket_alloc_t *allocator,
     apr_pool_t *pool);
 
 /**

Modified: commons/serf/branches/gen2/test/serf_get.c
==============================================================================
--- commons/serf/branches/gen2/test/serf_get.c	(original)
+++ commons/serf/branches/gen2/test/serf_get.c	Thu Oct 30 03:01:17 2003
@@ -367,8 +367,8 @@
 
     serf_allocator = serf_bucket_allocator_create(allocator, pool);
 
-    connection = serf_connection_create(context, address, accept_response,
-                                        NULL, closed_connection, NULL, pool);
+    connection = serf_connection_create(context, address,
+                                        closed_connection, NULL, pool);
 
     request = serf_bucket_request_create("GET", url->path, NULL,
                                          serf_allocator);
@@ -377,8 +377,9 @@
                              "Serf" SERF_VERSION_STRING);
 
     status = serf_connection_request_create(connection, request,
+                                            accept_response, NULL,
                                             handle_response, NULL,
-                                            serf_allocator, pool);
+                                            pool);
 
     if (status) {
         printf("Error: %d\n", status);