More on fP 6.0 features

[Fairlight]

This public service announcement was brought to you by Laura Brody:
> On Fri, 22 Oct 2004 16:57:28 -0400, Fairlight <fairlite at fairlite.com> wrote:
> 
> > BASE64( TO|FROM , INFIELD, OUTFIELD)
> >
> 
> I already wrote a prc table that does this. Not very
> difficult.

So has Brian White, if memory serves.

"Inline is simply more efficient."  There was a reason they actually
implemented khttpd in linux.  Like a 3-10x performance increase over apache.
Just as an example.

I never said it was difficult.  I've read the RFC--it's not a problem.  The
implication is that it's desirable to have it as a builtin, not an extra
chunk you have to drag with you and run (for all intents and purposes) in
emulation, when it could be fully optimised and embedded.

Hey, I've written an XML parser as an external prc as well.  Even if I
bothered to make a generic one rather than a purpose-specific one, it's
simply going to be more efficient and flexible inline.

Of course, if "you can do it in a prc[, no matter how clumsily]" is the
criterion for rejecting feature suggestions, I would submit that that's a
grievous tactical error.

They're already (supposedly...the rumour mill has it) working on an XML
parser/importer.  If I bring in that contains base64-encoded data to avoid
stomping on the XML itself, why on Earth should I have to use a prc to do
something that should be a function of the inline parser?  "Hey, let's
provide the engine and the caboose, but get that boxcar out of there, it's
wasting space and I don't feel like making the coupling!"

At least that's how it sounds from this side.  No offense, but I don't
understand your objection to the inline function suggestion.

mark->
-- 
Bring the web-enabling power of OneGate to -your- filePro applications today!

Try the live filePro-based, OneGate-enabled demo at the following URL:
               http://www2.onnik.com/~fairlite/flfssindex.html