On Mon, May 17, 2010 at 15:35, C. Michael Pilato <cmpil...@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
