incubator-triplesoup-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: libapreq2?
Date Thu, 03 May 2007 20:56:24 GMT
Leo Simons <> 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.

Joe Schaefer

View raw message