On Tue, May 18, 2010 at 13:31, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> 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 hear ya, and that's why I suggested "copy the body into a $MAX-sized
buffer, then parse it". Setting MAX to (say) 64k would provide lots of
room for whatever is being requested. And should we need a larger
size, code for fancy parsing could be done in the future.
> 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).
Understood, and while I might tend to agree... it is hard to get away
from protocols. We can rewrite code all we want to move from "good
enough" up to "perfect". Protocols don't have that luxury,
unfortunately. We would always be stuck with "good enough" even in the
face of "I have time to make it 'perfect', but no longer can..."
Thus, my concern about taking a shortcut today.
> I'll revert what's been committed thus far, and possibly return again when I
> find a sufficiently sized block of time.
Yah, I was kinda surprised to see it go in there so quickly. Wasn't
expecting other needs for the body in 1.7. But thanks for backing out
the XML stuffs!
Cheers,
-g
Received on 2010-05-18 20:57:15 CEST