I've finally got around to playing around with the support for darcs 
send to send its payload to an HTTP POST rather than an email.  It will 
work for my needs as is (after learning my way around Python's email 
parsing library), but I've collected a small list of nice-to-haves that 
would make the tool even more useful in future versions and to future 
users and web developers.

* Flag support for POST: either recognize when --to begins with http:// 
or add a --post flag so that HTTP POST may be utilized without 
$remote/_darcs/prefs/post.

* HTML response support: darcs dumps the server response to standard 
out.  If a server responds with a large HTML response, as an HTTP server 
may be prone to do, especially for 404/500, this ends up (to an 
oblivious user) as fast scrolling garbage.  It would be really nice if 
darcs could redirect this to the user's default web browser...

* Well-formed POST support: currently darcs send simply creates an HTTP 
POST with the body of the POST no different from the email that darcs 
would send to a mailer.  An HTTP consumer can't use their web 
framework's standard POST parsing to deal with the request, which 
appears malformed with respect to normal POST key-value pairs, and 
instead need to find out how to get the raw request and then use an 
email parsing library.  Email format and POST request format are 
somewhat similar property bags (key-value pairs) and it would be nice if 
darcs directly output a well-formed POST request (with necessary 
encoding changes) and a true "REST" call, rather than requiring web 
authors to delve into email parsing.  (This may not be feasible; I 
assume it depends somewhat on the current abstraction level and/or 
willingness to transform data structures for this "special case" of send 
to POST.) --- On the other hand I can also see the argument for leaving 
this as-is in that a consumer might use some of the same parsing code 
for both send emails and POSTs...  I think more web developers would 
prefer the tools to which they are accustomed over some potentially 
small savings in shared code between two fairly different input systems, 
but who knows.

None of these are critical, but I thought they should be written down 
before I forget them.

Hi Max,  would you mind filing these as separate requests?  Thanks.