C. Michael Pilato wrote:
> 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.)?Actually, scratch the "text/plain" bit. We send non-human-readable stuff across the wire, too. (Perhaps use a custom MIME type to indicate skelful content?) -- C. Michael Pilato <cmpil...@collab.net> CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
