Very Computer

Ok , here is what I have done. I have written a socket server (based on the work of Pete Jewell) in pickbasic that sits & listerns to port 5000 (on D3) , then on my browser when type in my d3 machine's ipaddress:5000 it connects to my socketserver.
This is the stuff that my browser sends to d3:

Response from client : GET / HTTP/1.0
Via: 1.0 S_PROXY01
Connection: Keep-Alive
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
Host: (ipaddress):5000
Accept: */*
Accept-Language: en-za
Pragma: no-ca

then I send some html back to my browser.

This is all nice , BUT now I have a input box on the html and I want to send that value through the socket to put it in the database, what should I do to 'submit' a value.

Thanks

Quote:

> Ok , here is what I have done. I have written a socket server (based on

Quote:> This is the stuff that my browser sends to d3:

> Response from client : GET / HTTP/1.0
> Via: 1.0 S_PROXY01
> Connection: Keep-Alive
> User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
> Host: (ipaddress):5000
> Accept: */*
> Accept-Language: en-za
> Pragma: no-ca

> then I send some html back to my browser.

> This is all nice , BUT now I have a input box on the html and I want to

Quote:

> Thanks

There are a number of free HTTP Servers available with source in VB and
other languages.  It's a good learning experience to setup a web page, make
requests of these servers, watch the inbound and outbound data at the detail
level, then try to mimic the behavior in your D3 code.  (I don't mean source
code where the protocol activity is done for you, make sure it's
socket-level code.)  Note that GET and POST submits are handled differently.

Also be careful about which protocol you're supporting and which one the
Client is using: HTTP 1.0 or 1.1.  It might seem like a pain, but get RFC
2616 for HTTP/1.1.  I've got a copy on my desk in front of me now.  You have
to do some reading to implement standard protocols.

Are you aware that FlashCONNECT is now free?  You can do everything that
you're talking about without having to deal with the socket layer.  If
you're doing this for fun then stick to the sockets, but if you're doing it
for a business app then use tools that are already available.

Feel free to ask more questions if necessary.
Tony

remove avoidingspam

Quote:

> Ok , here is what I have done. I have written a socket server (based on

Quote:> This is the stuff that my browser sends to d3:

> Response from client : GET / HTTP/1.0
> Via: 1.0 S_PROXY01
> Connection: Keep-Alive
> User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
> Host: (ipaddress):5000
> Accept: */*
> Accept-Language: en-za
> Pragma: no-ca

> then I send some html back to my browser.

> This is all nice , BUT now I have a input box on the html and I want to

Quote:

> Thanks

Quote:

>Ok , here is what I have done. I have written a socket server (based on the work of Pete Jewell) in pickbasic that sits & listerns to port 5000 (on D3) , then on my browser when type in my d3 machine's ipaddress:5000 it connects to my socketserver.
>This is the stuff that my browser sends to d3:

>Response from client : GET / HTTP/1.0
>Via: 1.0 S_PROXY01
>Connection: Keep-Alive
>User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
>Host: (ipaddress):5000
>Accept: */*
>Accept-Language: en-za
>Pragma: no-ca

>then I send some html back to my browser.

>This is all nice , BUT now I have a input box on the html and I want to send that value through the socket to put it in the database, what should I do to 'submit' a value.

>Thanks

 Glen
  http://www.picksource.com

I am running D3 on linux 5.2 , yes I know Apache & FlashConnect are free & the project is for a front end to only dispay data (no input). The reason why I want to write my own server is 1st to get a better understanding of sockets & second , if I am correct flashCONNECT only work for D3 so if I want to do the same on another MV database i think i will still be able to write the socket server on another MV database.

I'd advise you not to write an HTTP server just for cross-platform
compatibility, however.  Following up to Glen's points:
    Raining Data has already committed to a port of FlashCONNECT over mvBase
and Universe.  mvEnterprise and/or Unidata might be in there too, I dunno.
John Lombardo may be able to say if the code was written, but check with
your VAR or RD to see what the RD roadmap says.
    FlashCONNECT is a pipe from the web server to D3, with an API in D3 to
process input and generate output.  Even if you have FlashCONNECT, you will
still need a web server.  You can use your own, but it will be much easier
with Apache or IIS.  Writing a socket server in other environments is not as
easy as in D3, just check the other recent postings (also by Big John
Lombada).
    Are you really using HTML in the client?  For example, I wrote a demo
that uses a microphone for input and speakers for output = speech I/O for
D3.  I wrote another that allows Shockwave multimedia to integrate with D3.
That was done through a web server and FlashCONNECT for the pipe, but no
HTML.
    Are you really looking for an HTTP server?  Why is HTTP your transport
and HTML your presentation, unless you're using a standard browser?  Have
you considered an alternate client or protocol?  If so, then you can write
the pipe any way you want and enhance it as desired.  That's exactly what
I've done and I'm using the connectivity component at the core of my
products.

Whatever you do, have fun.  I'd also recommend keeping your D3 current.  I
don't remember which version of D3 ran on 5.2 but it's OLD.  Maybe you meant
Red Hat 7.2?

Good luck,
Tony

Quote:

> I am running D3 on linux 5.2 , yes I know Apache & FlashConnect are free &

Quote:>I'll encourage you to write the HTTP server for your own benefit.  Be sure
>to read and understand the RFC's.

I think a good step to just learning sockets and design
structure, would be studying the SMTP protocol (822 I
believe), and building a tiny mail server. That provides
more 'common interactive' theory, than a hit and dump server
like HTTP. But, I'm not the one building it! :)

Quote:

>I'd advise you not to write an HTTP server just for cross-platform
>compatibility, however.  Following up to Glen's points:
>    Raining Data has already committed to a port of FlashCONNECT over mvBase
>and Universe.  mvEnterprise and/or Unidata might be in there too, I dunno.
>John Lombardo may be able to say if the code was written, but check with
>your VAR or RD to see what the RD roadmap says.

Quote:>    FlashCONNECT is a pipe from the web server to D3, with an API in D3 to
>process input and generate output.  Even if you have FlashCONNECT, you will
>still need a web server.  You can use your own, but it will be much easier
>with Apache or IIS.  Writing a socket server in other environments is not as
>easy as in D3, just check the other recent postings (also by Big John
>Lombada).

Quote:>    Are you really using HTML in the client?  For example, I wrote a demo
>that uses a microphone for input and speakers for output = speech I/O for
>D3.  I wrote another that allows Shockwave multimedia to integrate with D3.
>That was done through a web server and FlashCONNECT for the pipe, but no
>HTML.
>    Are you really looking for an HTTP server?  Why is HTTP your transport
>and HTML your presentation, unless you're using a standard browser?  Have
>you considered an alternate client or protocol?  If so, then you can write
>the pipe any way you want and enhance it as desired.  That's exactly what
>I've done and I'm using the connectivity component at the core of my
>products.

>Whatever you do, have fun.  I'd also recommend keeping your D3 current.  I
>don't remember which version of D3 ran on 5.2 but it's OLD.  Maybe you meant
>Red Hat 7.2?

  Glen
    http://www.picksource.com

Quote:>   Ports of FC eh? Is this based on the java socket server?

Quote:>  Eh Hem.. I though that the fccgi (which is an integral part
> of FC) only accepts HTML forms?

Regs,
John Lombardo

Quote:>    Are you really using HTML in the client?  For example, I wrote a demo
>that uses a microphone for input and speakers for output = speech I/O for
>D3.  I wrote another that allows Shockwave multimedia to integrate with D3.
>That was done through a web server and FlashCONNECT for the pipe, but no
>HTML.

That is the reason why I want to write my own webserver aswell , if we have to move to a new server , I can simply move my source to the new server and don't have to worry about setting up FC or a webserver or whatever you you are going to use.

And another reason is that we use System Builder , and if I use my own webserver I can control to what account to switch to & and can change SB so that its I/O is compatable for the web.

Quote:> Why would you want to use FlashCONNECT if you can write a simple socket
> server in D3 and with the VB voice controls , convert voice to text , send
> the text , get the result from d3 and then text-to-speech back ?
> Then there is no hassle of setting up a webserver or flashconnect.

DONE:        You don't have to write it or support it.  A lot of
             time went into making FC fast and efficient, time
             that would have to duplicate.
FIREWALL:    Since the D3 connctions are outbound, you can put
             your database safely behind a firewall while your
             server lives outside.  This is a good thing.  
             Having your database on the wrong side of a
             firewall is foolish in this day and age -- if you
             have valueable data, you will get hacked.  This may
             not be important for the text-to-speach app, but
             it's critical for a webserver.
MULTI CNECT: You can't easily fork() a d3 pib. Because of this,
             you'll get all the performance that a single
             threaded basic program can give you (not much).
             There is probably a way around this by opening the
             socket in a little C program than then fork()ed
             and exec()ed D3 several times.
CRSS PLTFRM: Today: D3 (NT/Linux/AIX/...), mV(You Pick), Universe
             Tomorrow: Unidata?, jbase?  I don't work for RD
             anymore, so I can't say, but if there's a
             substantial market, then there's no technical reason
             that FC can't be ported to any of these.  Sheut, it
             could be ported to R83 if someone were to pony the
             dollars.

Quote:> That is the reason why I want to write my own webserver aswell , if we have
> to move to a new server , I can simply move my source to the new server and
> don't have to worry about setting up FC or a webserver or whatever you you
> are going to use.

An interesting question would be to ask Doug Dimitru (sp?): how long
it took to write just the HTTP piece of Coyote?  This is essentially
what you're doing.

Contrast this to the task of setting up Apache (it's probably already
done), then setting up FlashCONNECT.  Once you understand the process,
FC is a snap to install.

Quote:

> And another reason is that we use System Builder , and if I use my own
> webserver I can control to what account to switch to & and can change SB so
> that its I/O is compatable for the web.

o   Part of the w3apps item that defines what application to run given
a w3exec on the URL is the account to run it on.

o   The whole idea behind a persistant app is to allow you to move an
application that was designed to run from top to bottom (like most
are) and gently move it to the web.

Ok, I'm probably the worlds worst FlashCONNECT appologist since I
wrote the original version, wrote FCServer, fccgi, fcisapi and did the
Universe port -- but the fact remains that FlashCONNECT is a really
good way to get data into and out of the D3 database.  It's fast,
efficient, cross platform, and supports many simultaneous connections.

My $0.02
John Lombardo

Quote:>>   Ports of FC eh? Is this based on the java socket server?
>No.  The basic is re-tooled to the new DB.  Search CDP for "FCEXEC"
>for more details on how it was accomplished.

Quote:

>>  Eh Hem.. I though that the fccgi (which is an integral part
>> of FC) only accepts HTML forms?

>Funny, I just wrote a post on this last night.  Check out the Perl ->
>FlashCONNECT -> D3 post.  It details how to connect Perl to D3 using
>FlashCONNECT as a pipe.  FC makes a _really_ good pipe into D3 ...
>it's not perfect, but it's very very good.

Also:
 It's pointless to spend weeks or months writing a tech
article to help others learn, when the software you're
explaining changes often and drastically enough to
invalidate the content of the article when it's finally
done. Phew.. holy run-on sentences, batman!

Regards,

  Glen  - The argumentative one
    http://www.picksource.com

[ ... most snipped ... ]

Quote:>An interesting question would be to ask Doug Dimitru (sp?): how long
>it took to write just the HTTP piece of Coyote?  This is essentially
>what you're doing.

With Apache, you have a thread for each web "connection".  In unix,
this means a lot of processes.  Unix processes are light weight enough
that you can get away with this.  Pick processes are not so sparing.
Do you really want to run a D3 system with 1000 phantoms (or worse,
1000 paid seats) to handle peak load web requests.

The solution in Coyote was to write a low-level "socket" layer that
supports buffering, queueing, intelligent activity timeouts, and a
shared handle approach that allows handles to float from process to
process.  This lets D3 (or other mvDBMS products) services a very
large number of concurrent HTTP streams from a much smaller number of
D3 processes.

Coyote is also different from FC in the scope of it's HTTP
implementation.  FC is a client to Apache or IIS.  It cannot really
handle "raw" HTTP transactions.  Coyote is the server so everything
that the server can see is visible to Coyote applications.  If you
want the raw HTTP POST string, it is in a variable.  If you want to
query the stacks for the remote IP address of the actual network
connection, that is in a variable as well.  For web applications, this
is not too different from FC, but when you start trying to talk to
other systems using HTTP as a generalized transport layer, it is
extremely powerful.

Finally, programming web applications in Coyote is very different from
programming web applications in FC.  While some of the HTML concepts
are the same, the actual interfaces are very different.  FC is
basically an HTML string manipulator that uses subroutines to build
merged HTML output (I know that I am over-simplifying this here).
Coyote comes much closer to merging HTML and Pick/BASIC as a unified
environment.  FC applications tend to be littered with hundreds of
calls to the "w3c..." subroutines.  You use them for page merges, to
read form variables, etc.  Coyote applications tend to be a mix of
HTML and BASIC.  Output merges are accomplished by adding BASIC
expressions directly within the HTML.  Form field retrievals are
either handled automatically (for persistant applications) or with the
much more natural PL_GETVAR ... statement (PL_GETVAR is a statement
that you use in Coyote applicatons that has the same syntax as a
"READ" statement.  Instead of reading an ITEM from a FILE, it reads an
input field from a form).

Finally, Coyote lets you deploy applications with a very different
license model.  FC is now free on D3, but I am sure will cost money on
U2, etc.  Using FC is not free however.  You still need licensed D3
ports.  And if you are using the "easy to program" top down FC
environment, you need a D3 port for every concurrent user.  This can
make FC applications very expensive and usually prevents you from
using the top-down approach for any type of public internet
application.  Coyote is not free.  Current pricing ranges from $1495
to $5995 depending on how much traffic you want to be able to support.
This is the equivelent of about 4 to 17 D3 "ports".  The actual Coyote
processing runs on "legal" D3 phantoms (by legal I mean that Coyote
does not hack D3 in any way to avoid licensing).  This lets you run
literally thousands of persistent, top-down web applications on a
moderately sized D3 system with pretty negligible D3 licensing
requirements.

<soapbox>
I guess my biggest gripe with FC is that it does rely on an external
server.  If you look at the industry as a whole, most products are
progressing to the point of having an HTTP server built into the
product.  You have Domino for Notes, Oracle's whatever they call it,
nearly every piece of hardware widget you imagine from print servers
to routers are managed with an internal HTTP server, and even the
webmin unix administrator has it's own HTTP server (completely written
in Perl no less).  For D3, U2, and jBase to rely on an external server
is a bit of a cop-out and only serves to decrease flexibility,
increase support costs, and slow performance.  This is the same as
using Accuterm to transfer files over a serial or TELNET connection
(no disrespect to Pete here).  It does work, but you look at it and
think that there must be a more direct way.
</soapbox>

Back to the original topic.  Coding an HTTP hit in BASIC is not really
that hard.  You basically:

  Read the first line of the stream
  If it looks like HTTP/0.9 you process it
  If it looks like HTTP/1.0 or HTTP/1.1 you continue reading up to the
    double CRLF pair (which some browsers send as only LFs)
  You parse the header fields
  If there is a POST body, you continue to read that many bytes
  You de-code the form fields and/or body "unquoting" as you go

This is the input side.  On the output side.

  You build an output document in a string
  Based on this document, you build a reply header (unless you are
    processing an HTTP/0.9 request)
  You send it down the pipe

If you comm layer can handle the reply all in one call (and can pass
sockets around from process to process), this is pretty easy as the
application can then go off and do other things.  If you have to run
single-process, you will need to have one D3 process per socket (which
might be OK, but might be complete ugly).

Fortunately, the HTTP spec is entirely clear-text and easy to
implement in just about any language with decent string handling.  I
would highly recommend that in addition to reading the RFCs, you also
look at some packet sniffer dumps to see how other servers and/or
client behave.  A lot of behaviours are "legal" by the RFCs, but are
not exactly what you might expect just by reading them.  This is
particularily true in the handling of stream close semantics, having
"extra" CRLFs between requests, etc.

Good luck.

--- Doug Dumitru
    EasyCo LLC

Doug Dumitru
EasyCo LLC
949 831-4774
http://easyco.com

When I wrote those demos, Pick Systems Marketing still didn't understand the
power of FlashCONNECT and only talked about it terms of "the web", HTML,
browsers, etc.  The term "the web" is not limited to browsers and HTML.  My
FlashCONNECT demos showed how FlashCONNECT is really two products in one,
first a data transport tool, and only secondly an API that allows processing
of inbound HTTP forms and outbound HTML docs.  Coyote is the same, though
the fact that Coyote is also an HTTP server sort of confuses that point.
Once Pick Systems/Raining Data understood the concept of using FlashCONNECT
as a pipe, they immediately translated that into mvDesigner.

Side note: They still haven't quite gotten they idea yet that the exact same
infrastructures used for mvDesigner can be used to make the Visual Basic IDE
a RAD tool for MV.  Same applies to Visual Age for Java, Code Warrior, etc.
Since they don't get anything for VB or Java runtime licenses, we probably
won't see those products from RD.  But in the big picture this would be much
better for the MV community than what they have now.  This is sort of what
Pete Schellenbach is doing with AccuTerm GUI.

Regards,
Tony
(please do not email to the sneakemail address used to post this article.)

Quote:> Then there is no hassle of setting up a webserver or flashconnect.

> That is the reason why I want to write my own webserver aswell , if we

Quote:

> And another reason is that we use System Builder , and if I use my own

Patrick

P.S. It works and is getting better with each release.