svn commit: rev 57 - commons/serf/branches/gen2

[gs...@apache.org]

Author: gstein
Date: Tue Oct 28 21:41:18 2003
New Revision: 57

Added:
   commons/serf/branches/gen2/STATUS
Log:
start tracking some open items

Added: commons/serf/branches/gen2/STATUS
==============================================================================
--- (empty file)
+++ commons/serf/branches/gen2/STATUS	Tue Oct 28 21:41:18 2003
@@ -0,0 +1,21 @@
+APACHE COMMONS: serf                                    -*-indented-text-*-
+Last modified at [$Date: 2003-09-18 10:59:57 -0700 (Thu, 18 Sep 2003) $]
+
+
+OPEN ISSUES
+
+  * rather than having serf_bucket_alloc_t, can we make
+    apr_allocator_t work "well" for bunches o' small allocations?
+
+  * memory usage probably needs some thought. in particular, the mix
+    between the bucket allocators and any pools associated with the
+    connection and the responses. see the point below about buckets
+    needing pools.
+
+  * the current definition has a "metadata" concept on a per-bucket
+    basis. however, to record this metadata, we really want to be able
+    to use apr_hash_t, which implies having a pool.
+    
+    we do have a respool associated with the response. how does that
+    get transferred to the individual buckets for their usage? what
+    about the request side of things?