[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r945280 - in /subversion/trunk: build.conf subversion/libsvn_ra_serf/commit.c subversion/mod_dav_svn/dav_svn.h subversion/mod_dav_svn/posts/ subversion/mod_dav_svn/posts/create-transaction.c subversion/mod_dav_svn/repos.c

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Tue, 18 May 2010 13:31:58 -0400

Greg Stein wrote:
> On Mon, May 17, 2010 at 15:35, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>> Greg Stein wrote:
>>>> 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!).
>> The primary bit of misfortune about our skel library is that it isn't
>> conducive to piecemeal generation of skel-string output. You can't really
>> say "print a string that contains a list opener" and then "print the
>> following N list items" and then "print the list closure". Obviously, this
>> speaks merely to the immaturity of the library (and a bit to its use thus
>> far only for relatively small pieces of information), so "it's a simple
>> matter of programming" to fix. :-)
>
> Happy to help out, if you can start sketching something (I'm hoping to
> do in-db props this week).

Unfortunately, after looking more at this, I think the effort required has
crossed my threshold of pain tolerance. I haven't the cycles to completely
create from scratch a skel-based HTTP protocol which can be incrementally
generated, streamily parsed, deal with errors which might need to be
embedded willy nilly into the stream, maintains some degree of human
readability, etc, merely for the sake of not extending the use of our
existing XML-based protocol that already does all those things (and which
will have to be forever maintained for compatibility anyway).

I totally understand where you're coming from about XML's limitations, and I
respect your experience and opinions on the matter. But all I'm seeing at
the moment is the perfect being the enemy of the good (enough).

I'll revert what's been committed thus far, and possibly return again when I
find a sufficiently sized block of time.

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

Received on 2010-05-18 19:32:37 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.