fpCGI failure, part 2

[Fairlight]

When asked his whereabouts on Wed, Mar 19, 2008 at 07:19:18PM -0400,
Bruce Easton took the fifth, drank it, and then slurred:
> be created vs. updated. Of course these are a breeze under OneGate,
> and I've only needed to do it via XML output, but OneGate optionally
> supports saving textarea output into separate files instead of in
> the XML output. (That I guess could be used for those really big
> blobs? - I wouldn't know - I'm fpblobophobic.)

With textareas that are defined -as- TEXTAREA, the contents of said field
are stored into a separate file, rather than just put into the XML data
stream (and thus a field) as with a normal field.

At that point, you have a file on disk with the contents of the field,
and you have the path to that file in fP.  What would be the advantage to
trying to cram something into a blob?  That'd be like trying to store a
TIFF in a blob or something, when it's already somewhere far more usable
and doesn't need extraction to use...where's the point in doing so?  The
only advantage I can see is if you can do boolean fulltext searches,
Google-style, on blobs.  Then it -almost- makes sense--although I'd rather
system/user out to a tiny grep-based search that told me what I needed to
know about a file or set of files, depending on the locations.  It might be
about as efficient, plus it could support perl extended regex.

Sidetrack of Irony:  I just now realised that you can actually store -any-
field as a separate file, simply by defining it as TEXTAREA in the field
definition file.  I never really thought of that before, but if you look
at the raw data streams in both encoding types, there isn't anything at
all special about textarea fields at all compared to normal fields, nor is
there a way to check to see if it was defined as a textarea on the browser
side form (unless you count looking for \n or \r, which -could- be injected
into the other fields by a non-browser client).  Other than file uploads, a
field is a field is a field as far as the encodings go.

So you could store pretty much any field except a true type="file" field
as a separate file, simply by definition.  Even that one case would store
something--the filename as known on the original client system.

I've never thought of this particular virtue of the feature before now.
Not sure how useful it is, but it might be handy in some way I'm not
imagining at the moment, to get the contents of a non-textarea field into a
separate file rather than the data stream with zero pain.

For what it's worth...

mark->
-- 
"Moral cowardice will surely be written as the cause on the death
certificate of what used to be Western Civilization." --James P. Hogan