httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+apa...@sunstarsys.com>
Subject Re: apreq-2 uploads as bucket brigades?
Date Wed, 22 Jan 2003 00:06:42 GMT
davidw@dedasys.com (David N. Welton) writes:

> Joe Schaefer <joe@sunstarsys.com> writes:
> 
> > Performance is one reason.  If we don't *need* apreq to use the OS's
> > filesystem for spooling, we shouldn't.  We can leave that up to the
> > application, but we could make it easy for them to pretend uploads
> > are always files by providing things like
> 
> >   apreq_upload_link(apreq_upload_t *upload)
> >   apreq_upload_seek(apreq_upload_t *upload)
> 
> > instead of just handing them a *FILE pointer to play with.
> 
> Forgive me if I haven't been following as closely as I should, but
> would it still be possible to get ahold of a FILE* somehow?  

I think so.  But I'd like to have the *FILE API to be lazy.
In other words, apreq shouldn't generate a *FILE internally unless

  1) the upload is too large to store in memory, or
  2) an apreq user (not a "hook author") wants to deal 
     with the upload data via FILE*, in which case apreq 
     can generate the FILE* handle if it hasn't already done so.

What I'm looking for is an internal brigade design that manages
such behavior, which is why I suggested using a meta bucket.

It would be really cool (hint) if someone took a crack at this while
I'm working on the rest of apreq-2's core.  On a related note, the 
header docs for apreq_tables.h and apreq_cookie.h are stable in the
current httpd-apreq-2 cvs, but certainly not complete.  People looking 
for things to do might want to have a look at fixing those, or 
contributing a documentation system (any favorites?), or writing unit 
tests for tables and cookies.  I expect to have a working core library 
within the next week, as well as one stand-alone environment available 
for testing.

> FILE*'s can be passed to Tcl to create new file handles, and this is
> something that I feel is useful, because it gives you a really simple
> API for dealing with smaller files, even if it's not terribly
> efficient.

It is useful, natural, and convenient.  I'd just like to avoid making 
it mandatory like we did with apreq-1.  XForms will present a new set 
of needs for our mfd parser, and the extra flexibility of brigades over
a vanilla FILE* pointer could be a really big winner there.

-- 
Joe Schaefer

Mime
View raw message