--- Jim Davidson <[EMAIL PROTECTED]> wrote:
> Fred,
>
> Yup -- there are a few places in the code where
> there's a Tcl API
> without a corresponding C API. And, the docs are
> out of date,
> especially in the C API. Happily the code is
> generally readable
> although that's a crappy answer to the poor docs.
>
Thanks, then I haven't just been looking in the wrong
place. ;-)
> Anyway, in this case we'd need a few things:
>
> - An Ns_File (or some other name) object which
> mapped to the
> underlying File struct
> - API's to get Ns_File's from an Ns_Conn.
Would this be an Ns_Set which gives the file contents,
similar to the result of Ns_ConnGetQuery(), keyed by
the form input name?
> - API's to get offset, lengths, and copy the content
> from the Ns_File
>
For each form input, I would be OK with a pointer to
the data and the length, with a warning that it should
be treated as read-only data. Reading down a bit, it
should also have a flag saying whether the data has
been written to a file, instead of being in memory.
> All that stuff is now just internal and accessed via
> the ns_conn
> command. I figured someone may want such API's
> eventually but you're
> the first to ask -- in general folks spend most of
> their time with
> the Tcl API's although the C API's are pretty good
> in general. In
> practice, the code wouldn't be so hard -- the docs
> would probably be
> more work.
>
> I'd suggest you try out the Tcl API
My first impression was that even in Tcl, file uploads
were a bit creaky. The examples I saw could only
handle a single file upload per HTTP request, and
there was some indication that the file content had
been written to disk. Is there a better interface I
haven't found yet?
> -- it could be
> used to handle all
> the simple stuff and you can add commands to do any
> weird stuff in
> C. For completeness, I'll go ahead and add the
> missing C API's but
> they'll show up only in the head version of the
> code, 4.5 or beyond,
> and may be a few weeks or so as other changes are
> backed up.
>
> BTW: The aolserver I/O model is designed to
> read-ahead all that data
> before dispatching to the threads for processing --
> if you're working
> in a low-memory environment that may not be great
> for you.
My particular application is being designed for a
reasonably high memory, but poor disk I/O system, so
this shouldn't be a major issue for me.
> There's
> some other (undocumented) features to spool "large"
> files to an open
> temp file but then the various API's (in Tcl and C)
> don't exist to
> work with such files, only the Ns_ConnContentFd
> function exists to
> get at the open fd.
Is this in 4.0.10?
[EMAIL PROTECTED] find . -type f -exec egrep
Ns_ConnContentFd {} \; -print
NS_EXTERN int Ns_ConnContentFd(Ns_Conn *conn);
./include/ns.h
[EMAIL PROTECTED] dirs
~/aolserver/aolserver-4.0.10
> Factoring out all that so
> in-memory and in-temp-
> file would do the right thing would be quite a bit
> more work to get
> right.
>
What's the size limit that triggers this behavior? Is
it configurable? Web searching only brought up CVS
commits and a ChangeLog entry.
> -Jim
>
>
Thanks,
Fred
____________________________________________________
Yahoo! Sports
Rekindle the Rivalries. Sign up for Fantasy Football
http://football.fantasysports.yahoo.com
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
