[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: Greg Stein <gstein_at_gmail.com>
Date: Mon, 17 May 2010 19:15:37 -0400

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).

Cheers,
-g
Received on 2010-05-18 01:16:04 CEST

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