Greg Stein wrote:
> More XML crap? Yuck, ugh, and bleagh.
> 
> On Mon, May 17, 2010 at 14:09,  <cmpil...@apache.org> wrote:
>> ...
>> +++ subversion/trunk/subversion/mod_dav_svn/posts/create-transaction.c Mon 
>> May 17 18:09:28 2010
>> ...
>> +/* Respond to a S:dated-rev-report request. */
>> +int
>> +dav_svn__create_transaction_post(const dav_resource *resource,
>> +                                 const apr_xml_doc *doc,
>> +                                 ap_filter_t *output)
>> +{
>> +  request_rec *r = resource->info->r;
>> +  apr_bucket_brigade *bb;
>> +  apr_status_t apr_err;
>> +  dav_error *derr = NULL;
>> +  const char *txn_name;
>> +
>> +  /* Create a Subversion repository transaction based on HEAD, and
>> +     return the new transaction's name in a custom "201 Created"
>> +     response header.  */
>> +  derr = dav_svn__create_txn(resource->info->repos, &txn_name, 
>> resource->pool);
>> +  if (derr)
>> +    return dav_svn__error_response_tag(r, derr);
> 
> This doesn't match the "int" return type you've defined, and it
> results in build errors (see the buildbots).

Hrm.  This from util.c:

int
dav_svn__error_response_tag(request_rec *r,
                            dav_error *err)
{
   ...

I'll look into this (and the other similarly unexplainable) return mismatch
you mentioned.

> Can I say again that I hate XML, and am very much -0.5 on using it in
> our protocol like this? These bodies have nothing to conform to, so
> there is no reason to use XML. If you're doing it for *expedience*
> rather than *propriety*, then I'd suggest taking short cuts now could
> hurt us in the long term. XML means we need to deal with escaping as
> we move forward. It is overly wordy. Hard to write parsing code. etc
> etc.

I have a local patch here that adds a mod_dav_svn utility function for
stringbuf'ing a request into a giant block of memory and parsing into a
skel.  I can certainly switch to that approach if you feel that strongly
about it.  Would you be okay with a documented requirement that these new
POSTs use "text/plain", skel input, where the first atom of the skel is the
POST operation verb ("create-transaction", "lock-paths", etc.)?

-- 
C. Michael Pilato <cmpil...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to