incubator-triplesoup-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Reid <da...@jetnet.co.uk>
Subject Re: libapreq2?
Date Thu, 03 May 2007 21:47:03 GMT
Joe Schaefer wrote:
> Leo Simons <mail@leosimons.com> writes:
> 
>> On May 1, 2007, at 4:29 AM, Joe Schaefer wrote:
>>> Although I haven't looked at the codebase yet,
>>> but this looks to me like it will be a fun project.
>>> I'd be happy to help out with some of the stuff
>>> I'm more familiar with, namely integrating Apache-Test
>>> and/or using libapreq2 for parsing inbound POST data.
>> Cool!
>>
>> I've already (guided by Garrett) tried to start doing some Apache-
>> Test usage. I don't really know much about libapreq2 at all.
> 
> Having briefly scanned the sparql-query spec, it looks to
> me like the protocol is basically urlencoded (or xml encoded)
> table data.  If so, that makes apreq a good fit, since
> its accessors are essentially table lookups.
> 
>>> Have you considered the idea of using libapreq2's parsing
>>> infrastructure for handing POST?  If not, I'd be happy
>>> to try and pitch the advantage of doing so, which
>>> hopefully outweight the problem of introducing a
>>> new dependency.
>> Please do! As far as dependencies goes I'm not too fussed really,
>> since it seems we already depend on the stuff libapreq2 uses.
> 
> The main advantage of using apreq is that it will provide
> access to the meat of the sparql-query protocol to any
> apache handler.  Clients of apreq all share the resulting
> parse data, which is in contrast to what usually happens
> inside httpd (first handler to parse it steals the show).
> If there proves to be an opportunity to develop things
> like authorization handlers or output filters
> around the protocol, apreq makes all that relatively
> trivial to do.  If there isn't, and the only thing
> that makes sense is a monolithic mod_sparql handler,
> than it still is a win to use apreq because parsing
> user input in C sucks.  It's better to use a library
> dedicated to the task instead of rolling your own.
> 
> For instance, it took quite a long time to work out
> the bugs in httpd's header parsing facilities, mainly
> because it's very easy for good programmers to take
> a relatively simple task like that and optimize their
> first crack at the code for simplicity and efficiency
> over safety and correctness.  I took a brief look 
> at mod_sparql's implementation and see some of the
> same problems there.  It wouldn't be hard to fix
> them, but I really believe we should use apreq's table
> API instead.

What problems? Be interested to see details...

Mime
View raw message