Initial revision

CVS patchset: 6073
CVS date: 2003/02/28 19:23:24

1 files changed, 104 insertions, 0 deletions

diff --git a/neon/TODO b/neon/TODO
new file mode 100644
index 000000000..555670638
--- /dev/null
+++ b/neon/TODO
@@ -0,0 +1,104 @@
+
+To Do List for neon                                      -*- text -*-
+-------------------     Id: TODO,v 1.3 2000/05/13 20:52:43 joe Exp 
+
+Please submit feature requests to <mailto:neon@webdav.org>
+
+1. Support for HTTP-extended authoring methods ala WebRFM etc; using
+   New-URI header etc.  Also support the BROWSE and INDEX methods.  The
+   protocol is documented at:
+   http://www.ics.uci.edu/pub/ietf/webdav/ns_dav.html
+
+2. Add proper domain support to authentication code. (requires full
+   URI parsing support). Need to tell the auth layer the server
+   details.
+
+3. Add a callback to determine whether a specific request should go
+   through the proxy server or not... based on URI, maybe method too
+   since lots of HTTP/1.0 proxies break on DAV requests?
+
+4. Better cnonce generation for authentication: use /dev/random or
+   whatever like mod_auth_digest.
+
+5. Add request hooks to remove all authentication code from
+   http_request.c.
+
+6. PUT/GET with ranges... http_get_range
+
+7. hip_xml/dav_207/dav_prop might need a revamp.
+
+   hip_xml: use an expat-esque interface; i.e. make hip_xml_parser
+   opaque and add API to set handlers rather than initialize
+   structures directly. Two problems need to be solved more elegantly:
+
+   1) Allowing "sub-handler" for allowing parsing property element
+   contents independantly of the overally 207 response parse.
+
+   2) Allow "mixed-mode" parsing of XML which mixes cdata + elements.
+
+   Probably, make hip_xml more of a "utility" layer rather than a
+   "driving" layer; abstract out expat/libxml, namespace lookups,
+   element name -> id mapping, easy CDATA handling...
+
+8. WebDAV class 2 locking. Problems: this requires parsing the XML
+   within a property element. This could be achieved by doing a
+   completely new XML parse of the property value returned by end_prop
+   from the 207 code, but this is a bit noddy. Options:
+
+   a) Ideally: extend hip_xml and the 207 layer to allow doing a
+   proper start/end_element/cdata parse of the XML *within* a
+   property. This is tricky since it means extending hip_xml to
+   *dynamically* determine whether to be in "collect" mode or not. Add
+   another callback for this?
+
+9. DeltaV support (http://www.webdav.org/deltav/). See also the
+   inversion project (http://inversion.tigris.org/) who might build a
+   versioning system over DAV.
+
+10. ACL support (http://www.webdav.org/acl/)
+
+11. DASL support (http://www.webdav.org/dasl/). Xythos have server
+    support for this (www.sharemation.com).
+
+12. SSL/TLS support... make it pluggable so we don't have to export
+    crypto-related code at ALL?
+
+13. Should we really be abort()'ing on out-of-memory? It makes a lot
+    of code MUCH simpler (esp. sbuffer_* usage).
+
+14. Nicer request-header manipulation... some kind of indexed data
+    structure, so we're sure we don't add the same header to the
+    request twice (e.g. Cache-Control). Must be at least as flexible
+    as sbuffer usage, though.
+
+16. Socket status notification (socket.c:sock_register_*) is awful.
+
+17. Should we really be i18n'izing the low-level error messages in
+    http_request.c, dav_207.c ? It seems nice and clever to, so the
+    user REALLY know what is going wrong with the server (probably),
+    but it is maybe a bit frightening.
+    
+18. PROPFIND/propnames support.
+
+19. libtool support, for proper shared libraries.
+
+20. Add full URI parser + handling. Or stop pretending we are doing
+    "URI" parsing, and just handle HTTP URL's.
+
+21. Storing multiple authentication "sessions" within an actual
+    http_auth_session, so I log into e.g. /foo/ and /bar/ (which
+    are not in the same authentication domain)
+    switch between them without having to re-enter passwords all the
+    time.
+
+22. Handle PROPFIND property error responses properly.
+
+23. Mechanism for aborting a request mid-response; e.g., when a GET
+    fails due to out of disk space, abort the download.
+
+24. In a PROPFIND response, if a property were to include e.g., a
+    DAV:multistatus element, this would not be handled correctly.
+
+25. A BSD C library has an MD5 implementation in the C Library...
+    support this. (someone who runs a BSD will need to do this)
+