More on fP 6.0 features

[Fairlight]

When asked his whereabouts on Tue, Oct 26, 2004 at 12:25:16PM -0400,
Kenneth Brody took the fifth, drank it, and then slurred:
> Fairlight wrote:
> > 
> > Confusious (John Esak) say:
> [...]
> > > 2) I truly believe that Ken's ;-) after the 6.0 reference was pretty clear
> > > that he was kidding. And, by the way, this is meaningless... but somehow
> > > important... I have seen and worked with a tiny POP3 client that Ken wrote
> > > before 4.8 came out! It was cool enough at a first shot of probably 30 lines
> > > of code to be a sellable app... but that's another story. :-)
> > 
> > How long has the network code been in filePro?  I was under the impression
> > just since 5.x.
> 
> Not sure what you mean by "the network code".

Given the presence of the network layer symbols being present in the
binary, and a history of past "hidden features", it wouldn't surprise me in
the least if there were already wrapper commands available that simply have
been held back in documentation.

SOCKETERROR
SOCKET
SYSTOSOCKET
SOCKETTOSYS
SOCKETCLOSE
BIND
CONNECT
LISTEN
ACCEPT
SEND
SENDLINE
GETPEERNAME
GETSOCKNAME
WRAPINFO
LISTBOX

I included the last two just for context.  That's from the strings output
against dcabe, and it's smack in the middle of the rest of the function and
keyword string literal section.  I feel pretty safe in surmising that it's
already been silently implemented in the language.

C'mon, Ken...I'm not a completely dull tack.  And this isn't a recent
discovery on my part.  I found this the better part of a year ago while
looking for a particular string in one of the binaries during a debug
section.

> > I didn't take his comment about writing a POP3 client as a
> > joke.  Done a 'strings' on *clerk on a recent version?  It's linked against
> > the network stack, no doubt about it--and this would have to be intentional
> > on the SCO binaries.  And I believe I know why it's there.
> 
> fileProGI is TCP/IP-based.  What reason(s) were you thinking of?

That's why it's in there at the -low- level, presumably, and is the reason
I figured the network stack was linked against at all.  That (from the
looks of it) you have wrappers in the actual language speaks to something
else entirely, since (to the best of my knowledge), people using fPGI don't
need to use these functions manually.  If they did, I doubt more than 1% of
them could get the thing to work.  And the biggest questions we've seen
here are how to fix the darned license file to get it operational.

> > So yeah, I
> > wouldn't doubt he has a functional POP3 client in filePro.  This will also
> > be good news for any future XML parser, since they'll need to retrieve
> > DTD's and schema that aren't included, but are instead linked.
> 
> Remember...  I have access to written-for-future-version features of
> filePro that I can include for myself with a simple change of a #define.

I'm fully cognizant of that.  I also know what I'm seeing, and then you've
forgotten to change a certain #define in multiple releases on multiple
platforms.  :)

> > I didn't take the smiley quite the same way, but I can't read Ken really
> > well most of the time.  I just don't know him well enough to be able to do
> > so accurately.  I defer to your judgement, since I believe you do.
> 
> Well, the OP did ask about importing e-mail into a filePro database,
> and I did have a way of doing it.  ;-)

True enough.  :)

The problem is that you'd need to process it with 32K buffer blocks, if
you're using dummy variables in the process.  You can't have a BLOB dummy
field, can you?  (Now -there- is an idea, if you can't yet--a "scratch"
blob file specifically for transient dummies, specifically to break the 32K
limit.)

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