On Mon, May 17, 2010 at 15:05, C. Michael Pilato <cmpil...@collab.net> wrote:
>...
>> 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)
> {
> ...
Oh. Hmm. Thought it was that, but I don't have the code checked out
yet, nor the line numbers to align.
> I'll look into this (and the other similarly unexplainable) return mismatch
> you mentioned.
Cool.
Seems that it is just the windows compiler being strict, but that is a
Good Thing!! :-)
On your dev checkout, gcc should have lots of flags/warnings, so it
may pop right out at you.
>> 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.)?
Much more preferable!
And note that skels are application/octet-stream since they can encode
binary data (one the ways it will be easier to support!).
Cheers,
-g
